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TPL 



The Text Processing Language. A 
text-file runoff program con- 
sisting of a set of text-processing 
primitive commands from which 
more complex commands 
(macros) can be built (as in Logo). 
Features include: 

• Complete customization of 
text processing through 
macro definition and expan- 
sion, looping structures, and 
conditional statements; 

• Adapts to any printer; 

• Pagination; 

• Text justification and center- 
ing; 

• Indexing and tables of con- 
tents; 

• Superscripts and subscripts; 

• Bolding and underlining; 

• Multiple headers and footers; 

• End notes and footnotes; 

• Widow and orphan suppres- 
sion; 

• Floating tables and 'keeps. 1 
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DBX 

Blocked Keyed Data Access 
Module. Maintains disk files of 
keyed data. Can be used for 
bibliographies, glossaries, multi- 
key data base construction, and 
many other applications. 

• Variable-length keys; 

• Variable-length data; 

• Sequential access and rapid 
keyed access; 

• Single disk access per opera- 
tion (store, find, delete) in 
most cases; 

• Multiple files; 

• Dynamic memory allocation 
for RAM-resident index and 
current "page" of entries; 

• Includes demonstration pro- 
gram and testbed program. 
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PDMS 



$50 
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CHROME 

Chromatography data analysis 
program: 

• Graphic display of analog 
data; 

• Panning and zooming; 

• Automatic peak-finding and 
baseline calculation; 

• Full interactive peak editing; 

• Computation of peak areas; 

• Strip charts on C. Itoh and 
LPSON printers. 



$100 



10$ 



PLANE 

Planimetry program: 

• Bit-pad entry of cross sec- 
tions; 

• Real-time turtlegraphics 
display; 

• Calculation of areas; 

• Saves calculations to text 



file. 



$100 



The Pascal Data Management 
System. A user-oriented data 
management system in which 
numeric and alphanumeric data 
are stored in tables with named 
columns and numbered rows. 
Currently being used for dozens 
of different kinds of business and 
scientific applications, from in- 
ventory management to laborato- 
ry data analysis. Includes over 20 
Pascal programs; more than 
10,000 lines of code. Main 
features include: 

• Maximum of 32,767 rows per 
file; 

• Maximum of 400 characters 
per row, and 40 columns per 
table; 

• Full-screen editing of rows 
and columns, with scrolling, 
windowing, global search/ 
replace, and other editing 
features; 

• Sorting, copying, merging, 
and reducing routines; 

• Mailing label program; 

• Reporting program generates 
reports with control breaks, 
totals and subtotals, and 
selects rows by field value; 
many other reporting 
features; 

• Cross-tabulation, correla- 
tions, and multiple regres- 
sion; 

• Video-display-handling 
module; 

• Disk-file-handling module. 

Many other features. UCSD for- 
mats only. 

$250 



Full-screen text editor; designed 
to be used either with TPL or by 
itself. 

• Full cursor control; 

• Insert mode with word wrap; 

• 'Paint' mode; 

• Single-keystroke or dual- 
keystroke commands; 

• Command synonyms; 

• Global search and replace; 

• Block move, block copy, and 
block delete. 

$50 
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SCINTILLA 

A log logit curve fitting program 
for radio-immunologic data; must 
be used with PDMS (described 
above). 

• Multiple protocol files; 

• Quality control files; 

• Four-parameter non-linear 
curve fit. 

UCSD formats only. $250 
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MINT 

A terminal emulation program for 
communication between com- 
puters of any size. 

• User-configurable uploading 
and downloading of files; 

• X-ON/X-OFF and 
EOB/ACK protocols; 

• Interrupt-driven serial input 
(for Prometheus Versacard in 
Apple II); 

• Printer-logging. 

$50 



For more information, call 919-942-1411. To order, use form below or call our toll-free number: 1-800-X-PASCAL. 

"(ln"N"c"use7-lJ06-642-"0949)"" 



Check appropriate boxes: 






FORMAT 


PRODUCT 


PRICE 


□ 8" UCSDSSSD 


D DBX 


$ 50 


□ 5V4 " Apple Pascal 


LJ PDMS 


$250 


D 5V4 " UCSD IBM PC 320k 


□ TPL 


$ 50 


Q8"CP/M SSSD 


D ZED 


$ 50 


□ 5V 4 "IBM MS-DOS 


D MINT 


$ 50 


□ 51/4 "CP/M Osborne 


□ SCINTILLA 


$250 




LI CHROME 


$100 




□ PLANE 


$100 



I I MasterCard 

(Please include card # 
and expiration date) 

pple and Apple Pascal are trademarks of the APPLE Computer Corp. IBM and IBM PC are trademarks of International Business 
lachines. UCSD Pascal is a trademark of the Regents of the University of California. Osborne is a trademark of Osborne Com- 
liter. EPSON is a trademark of EPSON America, Inc. C. Itoh is a trademark of C. Itoh Electronics. 



□ VISA 



□ Check 



□ C.O.D. 
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A division of Pascal & Associates, 
135 East Rosemary St., Chapel Hill, NC 27514 



About the cover: 

The cover computer graphics were created by 
computer artist Catherine Del Tito. The pro- 
gram was written for an Apple He and a Vec- 
trix computer system. 
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UCSD p-SYSTEM™ 

with UCSD PASCAL" 

FOR THE 

VICTOR 9000 



Standard Features 



System Foundation: 

Operating System 

Filer 

Screen Editor 

Utility Library 

UCSD PASCAL Compiler 

Utilities for the Victor: 

Keyboard Editor 

Character Editor 

Config 

Diskutil 

Remote 



Single key commands 
For file management 
Powerful text editor 
Fast development tools 
Only requires 128K 

Define your own keyboard 
Design character sets 
Define machine parameters 
Disk copy/format 
File porting 



• Native Code Generator - For faster execution 

• Turtlegraphics - 800 x 400 pixel access 

• RAMDISK Capability - For RAM above 128K 

• Assembler - 8086 with macros 

• Documentation: 
Owner's Manual 

User Manual/Supplement 
Architecture Guide 
Installation Guide Excerpts 
DEMODOC diskette - On line tutorial for 
p-System overview 



Optional Features 



Hard Disk Support Software - For internal hard disk 

FORTRAN 77 Compiler - Only requires 128K 

BASIC Compiler • Xenofile™ 

• Applications Software (call for information) 



• 8087 Support Software 

• Advanced Systems Editor 
- Convert CP/M files 




TDI SYSTEMS, INC. 

620 Hungerford Drive 
Suite 33 

Rockville, Maryland 20850 
(301) 340-8700 



TDI LIMITED 

29 Alma Vale Road 
Bristol, U.K. BS8 2HL 
0272 742 796 



UCSD p-SYSTEM and UCSD Pascal are trademarks of the Regents of the University of California 
Universal Operating System and Xenofile are trademarks of SofTech Microsystems, Inc. 
Victor 9000 is a trademark of Victor Technologies, Inc. 




Announcing a $10,000 Contest for the Best 
Article or Application Voted by the Members 



Dear Member: 



By now those of you in the United States 
have received a questionnaire and announce- 
ment concerning "Pascal News. " The reader 
survey is a very important element in our abili- 
ty to contain the cost of this newsletter. When 
we solicit advertisers, they want to know about 
the members: Who we are, What we do, How 
much we spend. I realize these are very prob- 
ing questions and you may feel they are too 
personal. To separate your name from your in- 
formation, the subscription card is a self mailer 
and the return envelope for the survey will 
assure your anonymity. Thank you in advance 
for your help. 

Let me explain the announcement of our 
name change from "Pascal News" to "Pascal 
& Modula2. " Pascal has encouraged and en- 
dorsed rational programming. The language 
aids in the segmentation of a job into small 
parts through procedures and functions. I have 
enjoyed learning and using this language, but 
Pascal does have limitations. 

Many limitations are part of the design of a 
teaching language. Pascal is a very nice base, a 
core, to which extensions have been added by 
every implementor. We have accepted this and 
published reports of large extension packages, 
UCSD Pascal, Concurrant Pascal and Path 
Pascal. 

These extensions were added to a language 
created for teaching programming principles. 
This design goal allows a general purpose 
language, but not an all purpose language. 
Nicklaus Wirth recognized these limitations 
and created a language that would contain 
Pascal's good features and satisfy the goal of 
an all purpose language. 

Modula-2, created in 1977, is that language. 
In this issue, you will read Modula-2 product 
announcements. In these announcements, and 
in other articles, claims are made that Pascal is 
finished, that Modula-2 should replace Pascal 
in all cases. Maybe. I believe Pascal can and 
should remain in the position for which it was 
designed. The premier teaching language is 



Pascal. The easy transition from Pascal to 
Modula-2 makes Modula-2 an excellent second 
year language. Restrictions are necessary in 
the introduction to programming and Modu- 
la-2's flexibility does not focus a student to 
basic principles. 

Of course I may be "all wet," but I believe 
Pascal should remain. 

Pascal's teaching tool strength, Modula-2's 
all purpose ability, and the relatively painless 
transition between them make Pascal and 
Modula-2 proper subjects for the Pascal Users 
Group. Pascal News should reflect this wider 
interest in content and name. The new name, 
"Pascal & Modula2, " keeps Pascal as the first 
name and can be found in the same place in 
periodical indices as "Pascal News." This 
should make the libraries happy. 

The new logo places Pascal within Modu- 
la2, a reference to Modla-2's ability for operat- 
ing system programming, above Pascal, and its 
ability for machine specific programming, be- 
low Pascal. I hope you welcome the change 
and contribute to the discussion and promotion. 

This brings me to the contest for $10,000. It 
really is a promotion. There are many ways to 
promote this newsletter and I have tried a few. 
One way is to keep the members we have now. 
I have promised four issues per year and this is 
the fourth of 1983. A renewal notice was sent 
out in January and I thank you for your sub- 
scription. In October the reader survey and 
subscription card were mailed and I hope you 
renew promptly. I placed a small ad in "PC" 
magazine. It is in their Blue Book section and 
will run from September 1983 through March 
1984 and should attract new members. An- 
nouncement of our name change and subscrip- 
tion information was sent to fifteen magazines. 
Unfortunately there are many Pascalers who 
do not know of the Pascal Users Group. 

I am now very familiar with the costs of this 
newsletter and can say that income closely 
matches costs. I also know that if membership 
exceeds 5,000, we will have a surplus. What 
would we do with this money? Well, I propose 
that it be used for a promotion, and I cannot 



think of a better promotion than to vote for 
the best article or application published in 
"Pascal & Modulal. " 

I do not know whether the prize will be win- 
ner take all or first, second and third place divi- 
sion of the money. Your letters will help me 
form the rules. 

The first rule is we must have 5000 mem- 
bers. Fewer members and we cannot afford 
this contest. 

Now, you may recognize a little circularity 
here. The promotion attracts members and in- 
creased membership allows the promotion. 
Because of my other responsibilities (wife, 
home, job and country) I need your help to an- 
nounce this contest in all quarters. If all 4000 
members will send one letter (i.e. to friends, to 
users groups, to fellow students, to magazines) 
to announce this contest and one new member 
joins per letter, well, I think you get the idea. 

Rule number two— all contestants must be 
members. 

One more idea. If this contest generates 
enough material and money the newsletter will 
be published more often. Please send your 
ideas. 
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A typesetting program called TeX, created 
by Donald Knuth, is available for the cost of 
distribution. 15,000 lines of Pascal code puts 
TeX in the nontrivial category. 

Basic information is available from two 
sources. The book "TeX and METAFONT" is 
available for $12. Digital Press, 12A Esquire 
Road, North Billerica, MA 01862. A new 
book, "TeX Book, " should be in print by the 
end of 1983 from Addison -Wessley. 

Continuing information is provided by the 
TeX Users Group (TUG). Membership is $30. 
TeX Users Group, c/o American Mathemati- 
cal Society, PO Box 1571 Annex Station, 
Providence, Rhode Island 02901, USA. 

"Small Talk," a language from the Xerox 
Palo Alto Research Center was revealed in the 
August 1981 issue of "Byte" magazine. The 
Small Talk virtual machine, a software inter- 
face to the real machine, was given to four 
companies. They agreed to debug the virtual 
machine and share information. 

I found it interesting that Tektronics imple- 
mented the virtual machine in Pascal. I under- 
stand that Tektronics internal programming 
uses Pascal or Modula-2. The papers regarding 
the Small Talk research are assembled in the 
book "Small Talk-80 Bits of History, Words of 
Advice. " This book and "Small Talk-80 The 
Language and its Implementation " are avail- 
able from Addison -Wessley. 

Andy Michel informs me of a version of 
"C," the Bell Labs language implemented in 
Pascal. Very interesting. 



A large part of this issue is devoted to a com- 
piler creator. With a language specification 
this program will write the compiler. I have 
been told this program is very valuable. Using 
it, a contract for a compiler was satisfied and a 
handsome profit gained. (Sounds good to me.) 

Robert Gustafson in a letter complains about 
the typesetting of this newsletter. Expense, 
time and typographical errors are his concern. 
When printing more than 2500 copies, typeset- 
ting reduces overall expenses. Typesetting con- 
sumes 3 weeks' time, not an unreasonable 
amount for a quarterly. 

Typographical errors are a problem and pro- 
grams are photographed from originals to 
avoid them. A better way to assure correct in- 
formation and dark, clean type is to capture 
the author's original keystrikes. Floppy disks 
and mag tape will do the job, but I would have 
to convert the many magnetic formats to one 
the typesetter could use. 

Computer networks may be a better solution. 
Networks force all submissions to a common 
format. From this, the typesetter will make on- 
ly one conversion to his format. If there is a 
consensus, I will establish a bulletin board and 
file system on the most popular network. 

Please send your ideas. This is a one-man 
operation and I appreciate and need your help. 

I hope you enjoy this issue. 



Charlie 



2903 Huntington Road 
Cleveland, Ohio 44120 



Publisher and Editor: 
Charles Gaffney 

General Consultants: 
Studio Graphics Advertising 

Production Manager: 
Spence Coghlan 

National Sales Representative: 
John Bachmann 



The Pascal & Modula2 is published for the 
Pascal Users Group and Modula-2 Users 
Group, 2903 Huntington Rd., Cleveland, Ohio 
44120. Pascal & Modulal is a direct benefit of 
membership. 

Membership dues are $25.00 U.S. regular, 
other forms of membership please inquire. In- 
quiries regarding membership should be sent 
to the above address. Magazine correspon- 
dence and advertising should be sent to the edi- 
tor at the aforementioned address. Advertising 
rates are also available from the above address. 
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August 22, 1983 
Dear Charlie: 

I have been a subscriber to Pascal News for 
a long time. According to the date on my mail- 
ing label, it looks like I will continue to be a 
subscriber well into the distant (85) future. 

I agree with many of the notes published in 
PN #26 concerning your contributions to the 
well being of Pascal News, particularly the 
general management and timely publication. 

However, I believe that PN is doomed to die 
because of one change you have made. Previ- 
ously, the magazine was printed using the orig- 
inal letters submitted by PN correspondents. 
This was an inexpensive method of getting the 
information out to the readers. Your current 
system of rekeyboarding all of the correspon- 
dence can only be costing you dollars without 
increasing the utility of the information. Also, 
as people decide they can do without PN for 
$25/year, your circulation will decrease. One 
of the previous attractions of PN was that 
since it was so cheap, it reached everyone. A 
reduced circulation will cause contributors to 
look for other distribution media. I realize you 
are saving money on postage, but since PN is 
sent out bulk rate, the savings are only a small 
fraction of the cost of typesetting. Since these 
typesetting costs are the same whether you 
send out 1 copy or 3000 copies, I predict that 
you will not be able to compete with other 
publications in the field and PN will die. 

If you return to direct printing of correspon- 
dent copy you will be in good company. The 
DECUS special interest group newsletters 
(RSX SIG for example) are printed from yechy 
LA36 printer copy. I read them cover to cover 
as soon as they arrive. There are also a lot of 
expensive stock market newsletters which are 
printed from typewriter copy. These sell for big 
bucks because the buyers are interested in 
TIMELY information, not typography and art 
work suitable only for decorating a coffee 
table. 

By concentrating on quick publication, I be- 
lieve you will find advertisers willing to pay for 
space in PN. Also, when it comes to selling ad- 
vertising space, 3000 subscribers are much bet- 
ter than 300! Another important criterion for 
an advertiser is knowing that what is sent to 
you will appear unchanged in the publication. 



I have noticed that there are a number of 
typographical errors in the typeset issues of 
PN. These are inevitable in a keyed-once, 
proof-read-once publication (I know the statis- 
tics, one of our programming systems typesets 
approximately 40% of the municipal bond is- 
sues in the U.S. Errors here are a no-no. As a 
consequence, we have done quite a bit with 
automatic proofreading and word processor 
telecommunications). If you use advertiser 
copy directly, there can be no problems later 
with omissions of important parts of the copy 
or inadvertent changs to prices, etc. 

You might consider including a question- 
naire in the next issue of PN. I'm sure that the 
majority of your current subscribers would be 
much more enthusiastic about paying $9/year 
for the latest information from your corre- 
spondents and advertisers printed "as is" than 
$25/year for the present "remassaged" format. 
If you choose an even lower price, advertisers 
will pay more for the resulting increased cir- 
culation. Simple economics! 

Sincerely, 

Robert D. Gustafson 

President 

Simulation Specialists Inc. 

609 West Stratford Place 

Chicago, IL 60657 



June 29, 1983 
Dear Editor: 

I enclose a short article, Two Pascal De- 
vices, for publication in Pascal News. I shall 
appreciate your acknowledgement and, if you 
use the article, a copy of the issue in which it is 
printed. 

Sincerely yours, 

Harley Flanders 
Professor of Mathematics 
Florida Atlantic University 
Boca Raton, FL 33431 

P.S, May I humbly suggest that you do not 
print the output of line printers or dot matrix 
printers. It is just too hard to read. 



July 5, 1983 
Dear Mr. News: 

This is to request address correction from 
that found on the label: 
Jeff Davis [81] 
135 Turtle Creek 
#1 Roper Mt. Rd. 
Greenville, SC 29603 
to the following: 
Jeff Davis 

6549 Quiet Hours Apt. #201 
Columbia, MD 21045 

I am entering this using an editor found in 
"Software Tools in Pascal," one of the best 
books on toolbuilding I've ever read, and print- 
ing out using a copy of "Prose" from an early 
copy of Pascal News recompiled on an Apple 
///! As you see, my interest is in learning by 
building tools in Pascal. 

By the way, there is a local bulletin Board 
system (my next tool may be a spelling check- 
er!) called Magus which is actually an operat- 
ing system written in Pascal by Craig Vaughn 
that is worthy of note. Ill suggest that he sub- 
mit an article describing it and see what his 
reaction is. 

As a last comment, I had been out of the 
country for a few years and only recently re- 
subscribed. How's Modula-2 doing in the 
states? I've ordered their documentation but 
version for my computer (Apple ///) somewhat 
tardy. 

Thanks and it's great to be back in touch 
with Pascal reality again! 

Sincerely, 
Jeff Davis 

May 31, 1983 
Dear Mr. Gaffney: 

We have purchased a Motorola EXORciser 
development system for developing 6809 based 
products. We contracted to an outside vendor 
for the initial software development on a new 
product. All software was written in HP64000 
Pascal. We will be doing all software mainte- 
nance and enhancement in house and we are 
reluctant to do this in assembly language. 
Therefore, I am attempting to find a Pascal 
compiler to run on the 6809 EXORciser which 
is as compatible as possible with the HP Pas- 
cal. I would appreciate any help you can give 
me on this. 

We also have a Texas Instruments DS 990 
minicomputer with a Pascal compiler which 
we would like to use for electrical and elec- 
tronic engineering support and development. 
Any information on available Pascal electron- 
ics packages would be helpful. 

Very truly yours, 

MILLER Electric Mfg. Co. 
Bruce A. Casner 
Project Engineer 
P.O. Box 1079 
Appleton, WI 54912 
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easier to use that compiler instead of the P, be- 
cause your machine is— as you write— similar 
to the 360. 

Sincerely yours, 

Prof. Niklaus Wirth 

Eidgenossische Technische Hochschule 

Instit fur Informatik 

ETH-Zentrum 

CH-8092 Zurich 



June 2, 1983 
Could you send me any information you 
have on Apple and JRT Pascal? Also, I would 
be very appreciative if you could recommend 
any books for someone who knows BASIC and 
6502 Asembler. 
Thank you. 

Larry Houston 
169 West 8th Street 
Peru, IN 46970 



December 10, 1982 
Mr. Gaffney: 

I read about Pascal News from a UNIX 
NetNews (a network of UNIX installations 
sharing news) article. Could you send me the 
back editions containing the Lisp compiler- 
interpreter (written in Pascal)? Enclosed is $15 
for the year of back issues containing the Lisp 
compiler. Send me a bill for shipping if $15 
does not cover it all. I am glad to see you con- 
tinuing this magazine. 



Respectfully, 
Fred R. Finster 
8549 Evanston Ave. N. 
Seattle, WA 98103 



December 20, 1982 



Dear Charles Gaffney (Charlie), 

I have been infomed that PUG (Australia) 
has distributed its last issue (#24) of Pascal 
News, and that the subscription list and 
balance of funds has been transferred to the 
U.S. 

According to my records, I was paid up 
through 1984 (renewed for 3 years mid- 1981). 

However, I understand that there will prob- 
ably need to be an adjustment, so please could 
you apply my outstanding subscription toward 
whatever extension is appropriate. 

Please, if possible, inform me what the final 
position is; I am very keen to maintain my con- 
tinuity of membership, as I think PUG is very 
worthwhile. 

Thanks a lot. 

Yours sincerely, 



G. A. Foster 

5/138 Clarence Road 

Indooroopilly 

Queensland, Australia 4068 



February 15, 1983 
Dear Mr. Shaw: 

I know that your job keeping going the 
PUG is a great one. As we create the Mexican 
Wang Users Group with 200 members now, 
after 4 years about 4 people do the whole work. 

Our company with 32 people has an obliga- 
tion to use an accumulative half hour daily to 
do some investigation; that is why we are in- 
terested in implementing the Pascal in our 
machine, a Want 2200-VS-80. 

I believe that our specifications were wrong 
when we asked for the Portable Pascal P4, be- 
cause we have not been able to get started. 

Dr. Niklaus Wirth wrote me that the PUG 
has an 360 IBM compiler. I would like to know 
how can we be able to get it, because our com- 
puter with very little modification can run 
IBM assembler programs. 

If I can do anything to help the PUG please 
let me know. 

Thanking you in advance for all the trouble 
I may cause, looking forward to your answer. 

Sincerely, 

Miguel M. Soriano Lopez 
Technical Director 
Data, S.A. 

Av. Homero No. 1425-1201 
Mexico 5, D.F. 



June 5, 1981 
Dear Mr. Soriano, 

It was a pleasure to hear from you after so 
many years. I fondly remember that stay in 
Mexico in 1963. 

I guess the best way to "get in touch" with 
me is by writing, as you did. However, I do not 
see a chance for me to visit Mexico in the near 
future, as I am quite committed and busy at 
my position here at ETH. 

Good luck for your Pascal compiler project. 
Are you aware of the compiler for the 360, al- 
so available from PUG? Perhaps it would be 



August 31, 1983 
Dear Charlie: 

I use Pascal at the National University of 
Mexico in a Burroughs 7500 or on a PDP-1 1, 
and at my work I am trying to install the Pas- 
cal-P you send me last year. 

Several doubts I had, I asked Dr. Wirth, 
who answer me and recommended that will be 
easy to implement the IBM-370 version, which 
is more similar to my Wang 2200-VS-80 
machine. 

On the 25th Pascal News is a report about 
an IBM-370 Pascal. I will like to know if 
Joseph A. Minor of Cornell Computer Services 
would like to work together with me, to give to 
the PUG a Pascal compiler for the Wang VS. 
Only in Mexico there are more than 200 in- 
stallations; I believe that at the USA are 
several hundreds who may be Pascalers, if the 
PUG will have it. 

I hope to hear from you soon, thanking you 
for the trouble I may cause you. 

Sincerely, 

Miguel M. Soriano Lopez 



May 26, 1983 
Dear Editor: 

I would appreciate it if you would publish 
the enclosed announcement of the availability 
of the Edison System Report entitled "Pro- 
gramming a Personal Computer" in the Pascal 
News. 

Yours sincerely, 

Per Brinch Hansen 

Henry Salvatori Professor of Computer Science 

University of Southern California 

University Park 

Los Angeles, CA 90089 
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FOR IMMEDIATE RELEASE: October 11, 1983 

Cleveland, Ohio: The ten year old publication, Pascal News is changing 
its format and name to Pascal and Modula 2, according to publisher, 
Charles Gaffney. 

For those unfamiliar with computer terminology, Pascal is a small and 
general purpose computer programming language, originally designed 10 
years ago by Professor Niklaus Wirth of Switzerland as a teaching 
language. Because Pascal is easy to learn and read, and can be efficiently 
translated by computers, it was adapted for use in business. However, 
it does have certain restrictions. To meet the increased demand for an 
all purpose programming language, Wirth designed Modula 2. The 
structure of Pascal is included in Modula 2, affording simple and quick 
transition for programmers. 

Pascal News was origninally established to be a forum of correspondence 
for the Pascal Users Group (PUG). Because of the close linkage between 
these languages, and the rapid growth in the day to day use of computers, 
Gaffney expanded the publication to include articles and correspondence 
about Modula 2. 

"Modula 2 is a newer language on the cutting edge of computer science," 
said Gaffney. "Its design allows Pascal to settle into original standards, 
and removes the pressure to be all things to all people." 

Modula 2, sold only under license, will be protected from incompatible 
revision. The new availability of Modula 2 from at least 4 vendors 
demands a forum for new users as well as Pascal users. Pascal and 
Modula 2 , sponsoring the Pascal Users Group and organizing the Modula 2 
Users Group, will provide that forum. 

Pascal News has over 4,000 subscribers in 41 countries, according to 
Gaffney who is confident the new publication will continue to serve 
these user groups. Pascal and Modula 2 will provide application 
software, software tools, articles on programming philosophy, the use 
of Pascal as a teaching tool, the promotion and application of each 
language, as well as an important open forum where users contribute 
informal correspondence of general interest to the group. 
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1. THE FORWARD DECLARATION 

It was brought to my attention by H. S. Wilf 
that the reserved word forward is not neces- 
sarily included in all versions of Pascal. If we 
examine Jensen and Wirth', we find forward 
discussed on page 82 of the User Manual, but 
not in Appendix C, Syntax, pages 110-115, nor 
in the railroad diagrams, pages 1 16-1 18; how- 
ever, in Appendix E, Error Number Summary, 
page 120, while nowhere in the Report, pages 
133-167. 

Suppose we have a program in which several 
procedures call each other recursively. The 
usual way to handle this is via a series of for- 
ward declarations. It is possible to accomplish 
the same thing without using forward at all. 
Suppose, for example, that we have the 
declarations 



procedure B 
procedure C 



forward; 
forward ; 



Procedure 

<^declarations> 
begin 

<stateir.ents Al>; 
end; 

procedure B; 

<declarations> 
begin 

Statements Bl>; 
end; 

procedure C; 

<declarations> 
begin 

Statements Cl>; 
e«d; 



statements A2> 



Statements B2> 



Statements C2> 



The following single procedure declaration 
does the same. 

var CONTPOL: Char; 

procedure ABC; 
'declaraticns> 
begin 
case CONTPOL of 

'A': begin ''statements Al>; 
CONTROL := B; ABC; 
Statements A2> end; 
'B': begin ''statements Bl>; 
CONTPOL := C; ABC; 
Statements B2> end; 
'C : begin Statements Cl>; 
CONTPOL := A; ABC; 
Statements C2> end 
end { case } 
end; { ABC } 

The statement calling ABC must initialize 
CONTROL to the first entry value. Clearly, 
many variations on this theme are possible. 



2. THE EXIT PROCEDURE 

UCSD Pascal restricts the goto statement so 
it only allows jumps within a block. Hence 
goto cannot be used to exit a nested sequence 
of procedures. The Exit procedure was intro- 
duced into UCSD to make up for this short- 
coming; however, it fails to do the job if the 
nested sequence happens to include recursive 
calls of a procedure. This can be quite inconve- 
nient at times. Suppose, for example, one is 
searching an array, and the search proceeds by 
testing an element then, if unsuccessful, it par- 
titions the array and tests the pieces recursive- 
ly. Of course, once the sought element is 
found, the search should be stopped. But the 
search procedure may be deeply nested at that 
time. 

A clumsy way out is to introduce a Boolean 
variable FOUND and rewrite the body of the 
search procedure as follows: 

procedure SEARCH; 
<declarations> 
begin 

if not FOUND then statements of SEARCH> 
end; 

The (external) call of SEARCH must be 
replaced by 

FOUND := False; SEARCH 

This is costly because it adds an extra test to 
each call of SEARCH. The following is an 
alternative using Exit. Assume that we are 
searching for X and that A denotes a test 
value. 



procedure DUMMY; 

procedure SEARCH; 
begin 

Statements of SEARCH> 
if A = X then Exit (DUMMY) 
end; 
begin SEARCH end; 



else . . . SEARCH 



Remember the UCSD rule is that Exit (PROC) 
is a jump to immediately after the most recent 
call of PROC, passing through all more recent- 
ly called procedures along the way, and doing 
some incidental housekeeping, like closing files 
those procedures opened. 

Reference 

1. K. Jensen and N. Wirth, Pascal User 
Manual and Report, 2/e, Springer-Verlag, 
1978. 
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Pascal compiler 



1.0 Introduction 



1.1 Background 



Zuse is a translator writing system written in Pascal which 
produces translators which are themselves written in Pascal. It 
is quite simple to use and alleviates much of the tedium inherent 
in writing a translator from scratch. It is named after Konrad 
Zuse whose visionary work on the programming language Plankalkul 
in the mid 1940s should be an inspiration to everyone. 

This user's manual assumes that you are already familiar 
with the principles of translator writing and syntax-directed 
translation. Such terms as "BNF grammar" and M LL(1) parser" are 
used freely without explanation. If you lack this background, 
you should refer to one of the standard texts on translator writ- 
ing (Aho and Ullman, "Principles of Compiler Design", Addison- 
Wesley 1977; Lewis, Rosenkrantz, and Stearns, "Compiler Design 
Theory", Addison-Wesley 1976; Pyster, "Compiler Design and Con- 
struction", Van Nostrand Reinhold 1980). 

Zuse has been designed to be highly portable across dif- 
ferent Pascal implementations. Only a handful of lines of code 
have been written using implementation-dependent features; e.g., 
Zuse presumes that type char is the ascii character set. This 
manual describes Zuse as it is implemented on Unix. A separate 
document describing any deviations from this manual should be ob- 
tained from whoever is responsible for Zuse's installation at 
your computer center. 



II 
\/ 

skeleton. o 

Fig. 1 Creating a Translator 
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Fig. 2 Executing a Translator 



1.2 How to use Zuse 

Zuse actually consists of two programs: generate . o - an exe- 
cutable program which accepts a translation grammar as input and 
generates several files which will be needed for the translator 
eventually produced; and skeleton . p - a partial translator writ- 
ten in Pascal which must be augmented by files produced both by 
you and by generate. o in order to become a complete Pascal pro- 
gram which can be compiled. Figure 1 shows the creation of a 
translator, skeleton. o. Figure 2 shows the execution of that 
translator to translate source string x. When creating a trans- 
lator, all of the files except for the user-defined translation 
grammar, and LLsup.i are part of or generated by Zuse. When exe- 
cuting the translator, only the source string which is to be 
translated needs to be provided by the user. LLgram is produced 
by Zuse. The particular manner in which Zuse creates the neces- 
sary files is described in later sections of this manual. 



Zuse's two programs are used in the sequence listed below to 
create a translator: 

1) Write a context-free grammar which specifies the syntax of the 
source language. The grammar should be prepared as a file us- 
ing any text editor. It can be stored under any fiLe name. 
Because of the parsing method supported by Zuse, the grammar 
must be an extended LL(1) grammar. The permissible extensions 
are specified in later sections. This grammar will eventually 
be used to produce a top-down left-to-right parser. 

2) Embed action code into the grammar which specifies the steps 
to be taken by the translator during parsing. A language de- 
finition with both a syntactic specification and action code 
is referred to as a "translation grammar". The translation 
grammar specifies the actions to be taken during the parsing 



of a string, 
source string. 



These actions produce a translation of the 



3) Prepare Pascal code which defines all supporting routines 
which will be called by the action code, including the lexical 
analyzer — LLNextToken. These routines, which will be needed 
when skeleton. p is compiled, should be stored in the file 
LLsup.i. 

4) Execute generate . o on the translation grammar just prepared. 
Generate. o expects the grammar to come from the standard input 
file so you must redirect your file: 

generate. o < MyFile 

Any errors it uncovers will be reported on the standard output 
file. Generate. o creates several Pascal text files which must 
be embedded into skeleton. p along with LLsup.i. Skeleton. p 
has been peppered with "include" directives so that these 
files will automatically be included during its compilation. 

One additional file will be created - LLgram. It is a 
modified version of the grammar specified in step 2, which has 
been compressed to facilitate use by skeleton . o, the compiled 
form of skeleton. p. Skeleton. o reads LLgram before transla- 
tion begins. 

5) Compile skeleton . p. If you are using the Pascal compiler 
"pi", then just type: 

pi skeleton. p; mv obj skeleton. o 

If you have another Pascal compiler, then invoke it in the 
standard way. Assuming there were no errors in the specif ica- 



tion of the grammar and the definition of the routines in 
LLsup.i, the resulting object code, skeleton. o, will be a 
working translator. If there are errors in the grammar, then 
all the steps just listed will have to be repeated. If the 
translation grammar is correct, but the support routines are 
incorrect, then they must be corrected and skeleton. p must be 
recompiled. You must repeat this process until you are satis- 
fied that the translator is correct. 



pression interpreter, 
tions are: 



For the three examples above, the transla- 
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6) Add error processing capabilities . Skeleton. o will detect any 
syntactic error in a source string. The detection and pro- 
cessing of semantic errors is left entirely in your hands as 
the translator writer. Skeleton. o's default error recovery is 
to terminate the translation, causing an appropriate message 
to be printed. Zuse also supports optional sophisticated er- 
ror processing facilities which allow you to specify a number 
of possible recoveries when a parsing error is detected. 
These are explained in section 7. 



1.3 Manual organization 

This user manual itself is organized into sections based on 
the steps just listed in section 1.2. A running example is used 
throughout to illustrate concepts as they are introduced. 

For further information about Zuse, the reader is urged to 
contact the author at the Department of Computer Science, Univer- 
sity of California, Santa Barbara, California 93106, phone: (805) 
961-3236 or x-4321. 



2.0 Write A Context-Free Grammar 

The first step in generating a translator is to prepare a 
context-free grammar which specifies the syntax of the language 
to be translated. A context-free grammar G classically has four 
components : 

• nonterminals - the grammatical categories 

• terminals - the alphabet of the language 

• axiom - a nonterminal which begins all derivations 

<s productions - the rewriting rules 

In fact, Zuse uses a somewhat different structure dictated by the 
need to distinguish between different types of terminals. Two 
classes of terminals will be defined: "groups" and "literals". 
Details about them are presented in section 2,3. 

The grammar specification is divided into declarations and 
productions . Each vocabulary symbol used in the grammar must be 
declared, indicating what type of symbol it is. Just as in Pas- 
cal, a symbol must be declared before it can be referenced. But 
before describing how to write the grammar, the language which 
will be the basis for a running example throughout the manual 
will be described. 

2.1 The language EXPRESSIONS 

At this point the language which will serve as the running 
example throughout the manual will be introduced. The language 
EXPRESSIONS contains possibly empty sequences of arithmetic ex- 
pressions terminated by semicolons. Its grammar is called 
G_EXPRESSIONS. The operators are four basic arithmetic opera- 
tions on integer values: 

.+ - * / 

Operands are unsigned integer literals. Some sample strings of 
EXPRESSIONS are: 

(3+4)*(5-6); 4-6; 4 / 6; 

12/3; 

3; 

The arithmetic operators follow common precedence rules; i.e., * 
and / are performed before + and -, with operations being per- 
formed left to right within precedence. Parenthesization can 
override any default precedence. 

The translation of a member of EXPRESSIONS will be its 
numeric value. Hence, the translator in this case will be an ex- 



■ inter- 

If you 

message 

in this 

since 

the only 



You will type in an expression from the terminal, and you 
preter will print its value immediately below your input, 
type an invalid expression, then an appropriate error 
will be printed just below the incorrect input. Hence, 
case there really is no "object code" for the translation 
the display of the expression's value on the terminal is 
desired output. 



2.2 Lexical structure of Zuse grammars 

2.2.1 Tokens 

Zuse grammars have much the same lexical structure as Pascal 
programs. Within a grammar a "token" is a sequence of printable 
characters which has no embedded blanks, tabs, or newlines. In 
certain cases it may be necessary to surround a token with single 
quotes : 

. • token . . ' 

because the unquoted token is part of the metalanguage used by 
Zuse to specify the grammar. For example, each production ends 
with a semicolon. Hence, it is impossible to have a literal 
semicolon as a terminal symbol on the right-hand side of a pro- 
duction unless it is surrounded by quotes: 



In other contexts where there is no ambiguity, the semicolon can 
be used without quotes. 

Tokens may start in any column. Blanks, tabs, and newlines 
are token separators. Blank lines may be freely inserted any- 
where in a grammar. For convenience in later discussion, the 
word "spacer" will be uniformly used to mean any positive number 
of blanks, tabs, and newlines. 

Zuse is sensitive to upper and lower case letters. For ex- 
ample, the following three symbols could all be declared as dis- 
tinct nonterminals in your gra 



PROGRAM program PrOgRaM 

so be very careful, especially if your Pascal compiler does not 
make such distinctions for identifiers declared in Pascal pro- 
grams. Even if your compiler would treat the three symbols writ- 
ten above as the same identifier, Zuse will not. 

The maximum permissible length of a symbol is 12. If you 
write a symbol longer than the permitted maximum, generate. o will 
print an error message and disgard all characters of that symbol 
beyond the maximum. 



2.2.2 Comments 

A comment may be inserted anywhere a spacer is allowed. 
Zuse comments have the form: 



(* 



comment 



*) 



This is one of the two formats for comments used in Pascal. The 
other form of Pascal comment ,{..}, is not allowed in Zuse be- 
cause the curly brackets are used for other purposes as described 
later. 



2.3 Declarations 

Every symbol used in the grammar must be declared, although 
the order of declaration is not significant. A symbol can only 
be declared once. Zuse will tell you if you declare a symbol 
more than once or reference an undeclared symbol in a production. 

The same basic format is used for all declarations: 

%SPECIFIER LIST OF SYMBOLS 
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The SPECIFIER, which is part of the same token as '%', and so 
cannot be separated from it by a spacer, indicates the type of 
component being declared: 

n N - nonterminal 

a A - axiom 

1 L - literal 

g G - group 

Note that either lower or upper case letters can be used. There 
are three other specifiers used for declaring other types of sym- 
bols, which are described later. 



2.3.1 Terminals 



It is important to realize that the word "INTEGER" used in 
the above declaration has no special meaning to Zuse. The symbol 
"gzorp" could just as easily have been used: 

%g gzorp (* stands for the integers *) 

"INTEGER" was chosen because it is a good mnemonic, but other 
equally good (but distinct) mnemonics such as "integer", "int", 
and "Integer" could have been selected instead. 



2.3.2 Axiom 

In addition to declaring the terminal symbols, you must also 
declare the nonterminals and indicate which nonterminal is the 
grammar axiom. The axiom of G_EXPRESSIONS, "Ax" is declared by: 

%a Ax 



Terminal symbols represent the lexemes of the source string. 
They are divided into two kinds — "literals" and "groups". For 
example, in a grammar for Pascal, we might find terminals de- 
clared for the keywords such as "do", "program", "begin", and 
"var", for operators such as ":=", "<>" , and "»", and for the 
identifiers and integers. Any sequence of characters with no em- 
bedded spacers can be declared as either a literal or a group. 

A literal represents itself; i.e., it is a symbol which 
literally appears in a source string. The terminals "<>", "var", 
and "=" are examples of literals. Reading a Pascal program, we 
would expect to find literal occurrences of these symbols. The 
other form of terminal is a group, which represents a collection 
of lexically related symbols such as the integers or identifiers. 

The grammar, G_EXPRESSION, has seven literal symbols which 
can be declared by: 

Zl +-*/() ; 

The order in which the literals are declared is not important, 
but every literal which will be used in a production must be de- 
clared. 

The "%1" could appear anywhere on the line ("%L" could have 
been used instead, but not "% 1" since no embedded spacers are 
allowed), followed by the list of literal symbols. Elements of 
the list are separated by one or more spacers. 



Literals can be 
number of separate 
clarations: 

%1 + (* additive ops *) 



declared over several lines, using any 
literal declarations. The sequence of de- 



ll * 
%1 / 

%1 ( 
XI ) %1 



(* multiplicative ops *) 



(* note ";" doesn't need 
quotes here *) 



is equivalent to the earlier declaration. 

At the translator-writer's, discretion, the lexical analyzer 
can group symbols into a syntactic category rather than relying 
on the grammar to do so directly. Doing so can sometimes simpli- 
fy the grammar significantly; this is usually true for integers. 
Since EXPRESSIONS contains positive integers, they will be used 
to illustrate the concept of a lexical group. 

There is such a large number of distinct integers that it Is 
impossible to enumerate them, yet they can certainly be con- 
sidered indivisible lexical units. To make it possible to write 
a grammar which does not detail how integers are structured and 
does not attempt the impossible task of enumerating them, the no- 
tion of a token group is introduced. The entire set of integers 
can be declared by: 

%g INTEGER 

Having done so, you can use the symbol INTEGER in productions to 
stand for any integer wherever a terminal symbol is legal. The 
lexical analyzer LLNextToken must contain logic to recognize and 
classify integers within the source string. The classification 
details are discussed in section 5. 



%A Ax 

This declaration can appear anywhere in the declaration section. 
It also has the effect of declaring "Ax" to be a nonterminal, so 
it should not be redeclared as a nonterminal elsewhere. If you 
forget to declare an axiom, generate. o will remind you. 



2.3.3 Nonterminals 

A nonterminal is any token containing no 
They are declared using the specifier 'n' (or 



embedded 
'N'): 



spacer. 



%n Asop Mdop E T E-list P T-list 

Nonterminal names are separated by one or more spacers. Note 
that nonterminals E-list and T-list include a hyphen, making them 
illegal Pascal identifiers, but perfectly valid nonterminals. 
All nonterminals are shown here on a single line, but they could 
just as well have been written over several lines as was done for 
the grammar literals. 



2.3.4 Terminating the declarations 

When all declarations have been stated, the declaration sec- 
tion is terminated by '%%'. Hence, the entire declaration sec- 
tion for G_EXPRESSIONS could look like: 

%a Ax 

%n Asop Mdop E T E-list P T-list 

%g INTEGER 

%1 + - * / ( ) ; 

%% 



2.4 Productions 



2.4.1 Alternative productions 

Once the declaration section is complete, the grammar pro- 
ductions must be specified. They follow the "%%" which ends the 
declaration section. All productions with the same left-hand 
side, called alternative productions, must be declared together. 
The format for declaring the set of alternative productions for 
some nonterminal X is : 

X = LIST OF SYMBOLS 



LIST OF SYMBOLS 



LIST OF SYMBOLS 



"=" separates the left and right-hand sides of the produc- 
LIST_OF_SYMBOLS is a possibly empty sequence of vocabulary 



where 

tion, _ _ 

symbols, and ";" terminates each alternative production. All 
nonterminals, literals, and groups used in a production must ap- 
pear in a declaration. Members of the list of symbols are 
separated by one or more spacers. 

The productions for G_EXPRESSIONS are: 

Ax - ; (* empty production *) 

= E ' ; ' Ax ; (* note the use of a quoted ; *) 
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E = T E-list ; 

E-list =* Asop T E-list ; 

= ; (* another empty production *) 

T = P T-list ; 

T-list = Mdop P T-list ; 



P - ( E ) ; 
= INTEGER 

Asop = + ; 



Mdop = * ; 

- / ; 

Note the use of both literals and groups in the symbol lists on 
the right-hand side of productions and the use of the quoted 
semicolon in the second alternative production for "Ax". The 
literal semicolon must be quoted to distinguish it from the end 
of the production marker. On the other hand, the declaration of 
the literal semicolon did not require quotes because a semicolon 
has no special significance in declarations. 



2.4.2 Selection set conflicts 

Because Zuse is based on LL(1) parsing, the selection set of 
each production must be computed. This tells skeleton. o which 
alternative production to select when it needs to expand a non- 
terminal while building the parse tree top-down for a source 
string. Generate. o will compute the selection set of each pro- 
duction for you. This computation is very tedious and error- 
prone when done manually, and its automatic computation is one of 
the more pleasant features of Zuse. 

The grammar for G_EXPRESSIONS given above is LL(1); i.e., 
there are no conflicts in the computed selection sets of alterna- 
tive productions. Sometimes, however, you will write a grammar 
in which the selection sets of two alternative productions are 
not disjoint. Generate. o will always inform you when this occurs 
by printing a message stating which alternatives have the con- 
flict, and which selection set element they share. The message 
will appear on the standard output device during the processing 
of the grammar. However, even if there are conflicts, generate. o 
will still produce a valid parser. It uses a default tie- 
breaking strategy whenever conflicts arise: If two alternative 
productions have a selection set element in common, the produc- 
tion which appears first in the grammar will be selected. The 
conflicting token will be erased from the selection set of the 
later occurring alternative. 

This tie-breaking strategy is fine provided it is con- 
sistent with how you envisioned the parse to proceed. However, 
Zuse provides an easy way to override the default tie-breaker 
whenever the default choice is inappropriate. This is nicely il- 
lustrated using the classic ambiguity involving the optional 
"else" clause of an if-statement. 

The ambiguity arises when considering nested if-statements : 

if p then if r then s else t 

can be parsed so that the else-clause is associated with either 
the first or the second if-statement, as reflected by the two 
physical nestings: 

if p then (1) 

if r then s 
else t 



if p then (2) 

if r then s 
else t 

The first nesting is common to most languages including Pascal. 
The problem is getting the parser to understand which nesting is 
meant. 

The ambiguity is reflected in a grammar which is not quite 
LLC 1 ; . Two alternative productions both contain the literal 
'e lse ' : 



IF_STMT = if PRED then STMT ELSE_PT 
ELSE PT = else STMT ; 



The selection set of each alternative of ELSE_PT contains "else". 
The presence of other tokens in these selection sets would depend 
on the other features of the language in which this statement is 
embedded. According to the default tie-breaking strategy of 
Zuse, the first alternative would be used. This corresponds to 
(1) above. 

To illustrate the statement of specific selection set ele- 
ments, suppose that the order of the two alternatives were re- 
versed. To achieve the same nesting, you would have to write: 



ELSE PT = 



else STMT %else ; (* choose this prod *) 



A specific selection set element can be written as part of a pro- 
duction. This list of terminals, begun by "%", and separated by 
one or more spacers appears just before the semicolon ending the 
production. Specifying "% else" tells skeleton. o to use the 
second alternative no matter which other alternative productions 
might also have "else" in their selection sets. Any production 
can be written with a selection set, although no two alternatives 
should specify the same selection set element. 

Since you can specify selection set elements, you must also 
have a way to indicate which production to select when the end of 
the source string has been reached. None of the declared termi- 
nal symbols is appropriate. "@" is a pre-defined group used in a 
grammar to signify "end of source". It can only be used in a 
selection set and in synchronization specifications (section 
7.2), never as an ordinary terminal on the right-hand side of a 
production. Note that since "@" means "end of source", it should 
not be used in other contexts. If you have a language in which 
"@" is a token, then declare a group such as "AT-SIGN" and have 
the lexical analyzer associate "@" with "AT-SIGN". 

Occassionally you may want to force the selection of a pro- 
duction no matter what the next token's value really is. This is 
normally used for error processing in which a production really 
contains nothing more than a specification of the error recovery 
strategy you want to employ. Forcing the selection of a produc- 
tion will ensure that the desired error recovery strategy is 
adopted. Otherwise, if the error occurred in the token which 
would have caused you to select the production with the recovery 
strategy, that strategy will not be applied. This is discussed 
in more detail in the section 7 on error processing. 

In order to force the selection of a production, a pre- 
defined group element "any" is introduced. (All letters of "any" 
must be lower case.) Like "@", it should only be used in selec- 
tion sets and in specifying synchronization. It is used to force 
the selection of a production from among a set of alternatives. 

Suppose the current token is w and "any" is in the selection 
set of production p. If no previously occurring alternative to p 
has w in its selection set, then p will be selected, even if the 
current token is illegal. 

2.4.3 LLselect 

In a complex grammar it may be hard for you to anticipate 
what the selection set of particular productions will be. To 
help you debug your grammar, as well as for documentation, 
generate. o will optionally produce a reformatted grammar for you 
in file "LLselect". The reformatted grammar will be produced if 
you specify "%s" as a declaration anywhere in the declaration 
section. The reformatted grammar will contain the productions 
numbered in increasing order by line number from the original 
grammar. All error processing code will have been removed for 
easier readability, and all action code will have been replaced 
by the string "{a..}". Most important is the addition of the en- 
tire selection set of each alternative after all conflicts have 
been resolved. The messages stating selection set conflicts 
which were reported on the standard output during the execution 
of generate. o will be included at the front of LLselect. Appen- 
dix A contains LLselect for G_EXPRESSIONS and Appendix B contains 
LLselect for a preprocesor for FORTRAN. 

2.4.4 Terminating the productions 

The grammar productions are terminated in a manner similar 
to the way the declarations are, by writing "%%" where the begin- 
ning of a production is expected. 



12 



3.0 Embed Action Routines 



3.1 Format 



Once the grammar has been defined, you must add action code 
which specifies how the translation will proceed. Although this 
step can be done while the grammar is being written, it Is often 
more convenient and more reliable to first develop the grammar, 
embedding action code only after the grammar is complete. 

Action code may appear anywhere among the list of vocabulary 
symbols on the right-hand side of a production. The code is ac- 
tually a sequence of Pascal statements enclosed by curly brack- 
ets: 

'{a' Pascal statements '}' 

The first character after '{' must be an 'a' to indicate that it 
is action code. Other characters, discussed in section 7, are 
used for other types of code. 

Rewriting the grammar productions for G_EXPRESSI0NS to in- 
clude action code yields: 

Ax - ; (* empty production *) 

■ {a init} E {a writeln(popopand) ; } 

';' Ax ; (* note the use of a quoted ; *) 

E - T E-list ; 

E-list - Asop {a pushoptor($l. operator)} T 
{a r :« popopand; 
1 :» popopand; 
popoptor (op); 
if op » '+' then 
pushopand(l+r) 
else 

pushopand ( 1-r ) } 
E-list ; 

» ; (* another empty production *) 



T - P T-list ; 

T-list ■ Mdop {a pushoptor($l. operator)} P 
{a r :» popopand; 
1 :■ popopand; 
popoptor(op); 
if op - '*' then 
pushopand (l*r) 
else 

pushopand (1 div r)} 

T-list ; 



P = ( E ) ; 

■ INTEGER {a pushopand ($1. operand)} 

Asop = + {a $0. operator := '+'}; 
= - {a $0. operator := '-'}; 



Mdop = * {a $0. operator := 
= / {a $0. operator := 



'/'}; 



Several aspects of this revised grammar warrant explanation. 
For the moment ignore those strange looking identifiers which be- 
gin with "$". They refer to special variables which will be ex- 
plained in section 3.5. 

Action code specifies how the translation is to take place. 
All aspects of that specification are left in your hands. You 
can either write all of your code directly in the grammar or you 
can call separately declared procedures and functions from within 
the action code, or mix the two styles. The grammar above is 
written in a mixed style. The action code in the first alterna- 
tive for T-list has two assignment statements followed by a pro- 
cedure call, followed by an if -then-else statement. The action 
code for the second alternative of P has just a single procedure 
call. You must decide which support routines (as those user- 
defined routines called from action code are called) to define 
and what they will do. G_EXPRESSIONS has five support routines 
referenced in the action code: 



The declaration of these five routines must be included in 
LLsup.i, which contains the support routines, before skeleton. p 
can be compiled. However, at this point you only need to know 
what these routines do so that you can properly write the action 
code. 

The action code will map the infix expressions into two 
stacks — "opandstk" (operand stack) and "optorstk" (operator 
stack) — where the operands and operators of the expression will 
be held, respectively. The algorithm to evaluate infix expres- 
sions using two stacks is quite standard, and it is assumed that 
you are familiar with it. The code defining these five functions 
is specified in section 4. "Init" initializes the two arrays 
which represent the stacks and two integer variables, "topopand" 
and "topoptor", which point to the top of "opandstk" and "op- 
torstk", respectively. "Popopand" and "pushopand" pop and push 
elements onto opandstk, while "popoptor" and "pushoptor" are the 
analogous routines for optorstk. 



3.2 Variable, constant, type, and file declarations 

3.2,1 Variable declarations 

Two variables are referenced in the action code — "1" and 
"r". These variables hold temporary values of the left and right 
operands of some operator. Because Pascal requires the declara- 
tion of each variable which is referenced, there must be some 
provision for declaring these variables. Note that Zuse itself 
cannot have already declared them because the particular set of 
variables needed for the action routines will vary from transla- 
tor to translator. To permit user-declared variables, an addi- 
tional declaration type is permitted in grammars in the declara- 
tion section: 

%v Pascal variable declarations 

If a 'v' (or 'V') specifier is used in a declaration, then the 
variable declaration is copied verbatim into file "LLvar.i". 
Note that each declaration ends with a semicolon. If more than 
one variable is declared, they are copied in the order in which 
they appear in the grammar. 

G EXPRESSIONS needs several declarations: 



%v op: char; 



(* the operator popped from 
optorstk *) 



%v toptorstk: integer; (* top of optorstk *) 
topandstk: integer; (* top of opandstk *) 

%v opandstk: array [1. .stksize] of integer; 
optorstk: array [1 . .stksize] of char; 

%v l,r: integer; (* temps *) 

These six variable declarations can appear anywhere in the de- 
claration section. Since the order of variable declarations is 
not important in Pascal, they can be declared in any order. Note 
that several variables can be declared using a single "%v" as in 
the declaration of toptorstk and topandstk. 

3.2.2 Constant declarations 

The integer constant "stksize" is referenced in the declara- 
tion of opandstk and optorstk above. This constant and any oth- 
ers which you need for your action code can be specified through 
a constant declaration in the grammar. A 'c' or 'C is used to 
specify a constant declaration. G_EXPRE3SI0NS needs: 

%c stksize =20; (* maximum depth of stk *) 

Constant declarations will be placed into the file "LLconst.i" 
for inclusion into skeleton. p. They will appear in LLconst.i in 
the same order as they appear in your grammar. It is your 
responsibility to guarantee that a constant is defined before it 
is referenced. 

3.2.3 Type declarations 

Although they are not needed for this example, you can de- 
clare new types using the 't' or 'T' specifier. For example, if 
we wanted our interpreter to only work on nonnegative numbers, we 
might declare: 



init pushopand popopand pushoptor popoptor 



%t NonNegative = 0..maxint; 
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and substitute NonNegative for integer in the variable declara- 
tions : 



%v toptorstk: NonNegative; (* top of optorstk *) 
topandstk: NonNegative; (* top of opandstk *) 



Type declarations will be placed into the file "LLtype.i" for in- 
clusion into skeleton.?. They will appear in LLtype.i in the 
same order as they appear in your grammar. It is your responsi- 
bility to guarantee that a type is defined before it is refer- 
enced. 

3.2.4 File declarations 

The purpose of skeleton. o is either to interpret the input 
or to map it into some object code. It therefore must have a 
file from which the source string is read and, in the latter 
case, a file where the object code is placed. In addition, a 
complex compiler may also need several other files. The file de- 
clarations themselves can be handled as ordinary variable de- 
clarations. For example, if we wanted a to write a C compiler, 
the object code could be placed in a file called "object" which 
was declared by: 

%v object: file of char; 

The action code which produced the object code would write tc 
this file. 

An additional problem arises, however, because Pascal also re- 
quires that each file be listed in the program statement. Hence 
a %f declaration is introduced. The program heading for 
skeleton. p has the form: 

program skeleton( input, output, LLgram 
//include LLfile.i 

); 

If you wish to augment skeleton. p with new files, their names 
should be listed in a %f declaration, begun by a comma, and 
separated by commas. If we wanted to add an object and a message 
file to skeleton. p we would declare these variables by: 

%v object: file of char; 
message: file of char; 

and also declare the files by: 

%f , object, message 

The former would be included into the variable declaration sec- 
tion of skeleton. p, while the latter would yield the program 
statement : 

program skeleton( input, output, LLgram 
, object, message 

); 

3.3 Naming conventions 

Because Pascal is a block-structured language, the scope of 
declarations in skeleton. p is very important. You might acciden- 
tally select a name for one of your variables, types, constants, 
or support routines which already has been declared in skeleton. p 
at the same lexical level. This would cause a compile-time error 
when you tried to compile skeleton. p. To minimize the risk of 
such collisions all identifers in skeleton. p which are at the 
same lexical level as those identifiers which you will declare 
for inclusion within it begin with the characters "LL". For ex- 
ample, the main procedure of skeleton. p is called "LLMain". If 
you simply avoid declaring identifiers which begin with "LL" you 
should never encounter any difficulties. 



3.4 Parsing action 

Skeleton. o will construct a parse tree for the source string 
in a top-down left-to-right manner. The axiom you declared in 
the grammar will be the root of the parse tree. It will compare 
the first token of the source string against the selection sets 
of the alternative productions for the axiom. Assuming it finds 
a production with the required selection set element, it will ex- 
pand the axiom by hanging tree nodes from it corresponding to the 
right-hand of the selected production. It will then examine the 
leftmost child of the axiom which was just added. There are 



three types of nodes that child can be, depending on the kind of 
symbol from the right-hand side of a production which it stands 
for — nonterminal, terminal, and action. The translator's 
response will depend on which type of node it finds. 

If the child is a nonterminal node, the same process which 
was just applied to the axiom will be repeated for the child. 
The alternative productions of the nonterminal will be scanned to 
find one whose selection set matches the current token. Failure 
to find such an alternative indicates that the source string has 
a syntactic error, and error processing as detailed in section 7 
will be initiated. 

On the other hand, if the child is a terminal, the parser 
will compare the first token of the source string against that 
terminal. If they "match"; i.e, they are equal, the parser will 
advance to the right sibling of that node, and advance to the 
next token in the source string. At this point the whole process 
will be repeated with the particular action taken depending on 
whether the tree node is a nonterminal action code, or a termi- 
nal. 

If the child is action code, that code will be executed. 
Presumably this code will manipulate the variables declared in 
the grammar by "%v" declarations in order to effect the desired 
translation. Once this code completes execution, the parser will 
advance to the right sibling of that tree node, but will not ad- 
vance to the next token in the source string since nothing in the 
parse tree has been "matched" against it. 

When the right-most child of a parent nonterminal has been 
visited in the manner just described, the parsing of that nonter- 
minal is considered complete. Parsing continues with the right 
sibling of that parent node. This process iterates until an er- 
ror is uncovered, in which case the error recovery policy dic- 
tates what then happens, or until the end of the source string is 
reached, or until the entire parse tree has been constructed. If 
the end of the source string is reached before the entire parse 
tree has been constructed or conversely, the string is not in the 
source language and error processing is initiated. 

The order in which nodes are added to the tree and then ex- 
amined dictates when action code will be executed. For example, 
in G_EXPRESSIONS if the second production is selected when ex- 
panding axiom Ax, then the first thing the parser will do is call 
init, the action routine which initializes the data structures 
necessary to compute the value of the expression. Once initiali- 
zation is complete, the parser will attempt to expand E into a 
complete expression. Based on the other action code which will 
be executed during that expansion, the value of the expression 
will be on the top of opandstk when E has been completely expand- 
ed. At that point other action code is executed which causes 
opandstk to be popped, and the value to be printed. The parser 
then moves on to the semicolon, and finally to Ax. If this in- 
terpreter is to operate correctly, the other action code embedded 
in the remaining productions must ensure that the value of the 
string derived from E is stored atop opandstk. To understand how 
this is done, the use of synthesized attributes to pass informa- 
tion throughout the parse tree must be examined. 



3.5 Attributes 

The last feature of the action code which warrants explana- 
tion is the appearance of those strange variable names with a "$" 
in them. They arise from the use of attributes to pass informa- 
tion through the tree. 

Each node of the parse tree has associated with it a vari- 
able or "attribute" which can be used within action code to com- 
pute the translation of the source string. For G_EXPRESSIONS 
this attribute will be used to pass information about integers 
and operators in the source string. Because the use of the at- 
tribute will vary so greatly with the source language and its in- 
tended translation, it would be awkward to predefine the data 
type which the attribute has. Therefore, each grammar writer 
must declare the attribute data type using a type declaration: 

%t LLattribute = type-declaration 

The reserved name "LLattribute" must be used for this purpose. 

Since any Pascal type declaration can be used, a record can 
be declared to actually provide several distinct attributes. 
Hence, the restriction to a single attribute per parse tree node 
is not actually a hindrence. For example, G_EXPRESSIONS needs 
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some way to store both integer values and char values, leading to 
the declaration: 

%t LLattribute * record 

operator: char; 
operand: integer 
end; 

In fact, if you would prefer different nodes to have different 
attributes, rather than having each node have all attributes, 
this is readily achieved through a variant record: 



%t LLattribute 



record 

case selector-type of 
selectorl: (fieldl); 
selector2: (field2); 



end; 



selectork: (fieldk) 



In order to refer to an attribute, the action code must use a 
special naming scheme involving "$". "$" has a special meaning 
when used inside action code. If n is an unsigned positive in- 
teger, then "$n" refers to the attribute of the n-th vocabulary 
symbol on the right-hand side of the production in which the "$n" 
appears. "$0" refers to the attribute of the left-hand side of 
the production. In other contexts, "$ M has no special meaning. 
For example, the first alternative for E-list: 

E-list = Asop {a pushoptor($l .operator) } T 
{a r := popopand; 
1 := popopand; 
popoptor(op); 
if op = '+' then 
pushopand(l+r) 
else 

pushopand(l-r) ; } 
E-list ; 

contains action code which has "$1 .operator" in it. In this 

case, $1. operator refers to the value of the operator field of 

the attribute of Asop which is the first symbol on the right-hand 
side of that production* 

To better understand the way in which information is passed 
up the tree, consider the parsing of "3+4;". The derivation will 
begin constructing the parse tree: 

Ax 



{a init} 



I I I 

{a writeln(popopand)} ; Ax 



Init will be called to initialize the data structures, in this 
case, setting toptorstk and topandstk to be zero showing that no 
elements have been stacked yet. Then the parser will expand E, T 
and P in turn giving: 

Ax 



{a init} 



I I I 

{a writeln(popopand)} ; Ax 



E-list 



T-list 



I 



I 



INTEGER {a pushopand($l .operand)} 

At this point the parser will visit the node labeled INTEGER and 
match it against the current token "3" in the source string. The 
lexical analyzer should classify "3" as an INTEGER so that the 
match will succeed. The current token also has an attribute. 
The lexical analyzer will assign the integer value 3 to the 
operand field of that token's attribute. 

Next the parser advances to visit the action code which is 
to the right of the node labeled INTEGER. This action code will 
be executed causing $1. operand to be pushed onto the operand 



stack. The first vocabulary symbol starting from the left end 
among its siblings is the node labeled INTEGER which was just 
matched against "3" in the source string. Hence, the integer 
value 3 is pushed onto the operand stack. 

At this point the right-most child of the node labeled P has 
been processed. Hence, the parser would next visit the node la- 
beled T-list. The second alternative for T-list will be selected 
causing T-list to expand into the empty production. 



Redrawing the parse tree, eliminating nodes already 
which can play no further role in the translation gives: 



visited 



{a init} 



I I II 

E {a writeln( popopand)} ; Ax 



T E-list 

E-list and Asop now expand to yield: 
Ax 



{a init} 



E {a writeln( popopand)} ; Ax 



E-list 



I I III 

Asop {a pushoptor( $1. operator ) } T {a .. } E-list 

l 



{a $0. operator 



'+'} 



The first alternative production is selected for Asop because the 
current token is "+". The action code in that production assigns 
$0. operator the character value '+'. $0 refers to the attribute 
on the left-hand side of the production, which corresponds to the 
node labeled Asop. When that action code is executed, the opera- 
tor field of the node labeled Asop is assigned the value '+'. 

The next node visited is the action code to the right of 
Asop. It refers to $1. operator. This is the value just assigned 
to the operator field of Asop's attribute. 

This scenario continues a while longer until the entire 
parse tree is formed, but by now the basic information passing 
mechanism using attributes should be clear. 

There is a simple restriction on the use of attributes in 
action code which is dictated by the order in which the parse 
tree is constructed. An attribute must have a value before it 
can be referenced in action code. Since skeleton. o parses top- 
down left-to-right, $n in action code A only has a value if the 
n-th vocabulary symbol occurs to the left of A. For example: 



X 



Yl 



x := $2 



Y2 Y3 



would be nonsensical because the value of $2; i.e., the attribute 
of Y2, will not be known when the action code referencing it is 
executed. 



Although the reference to $2 makes no 
production, the very similar: 



sense in the above 



Yl {a 



$2 := x 



Y2 Y3 



which assigns a value to $2 is perfectly reasonable. The attri- 
bute of Y2 would be assigned a value which could then be passed 
down the parse tree when Y2 was expanded (assuming it were a non- 
terminal). This gives you the power of both synthesized and in- 
herited attributes. 

In fact, there is no logical reason why you should not be 
able to assign a value to the attribute of any vocabulary symbol 
anywhere in the production from any action code in the produc- 
tion. However, generate. o has a restriction on assigning values 
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to attributes forced by design decisions for generate. o. You can 
assign a value to the vocabulary symbol to the immediate right of 
the action code which contains the assignment — but not to any 
symbol further to the right. Hence, the production just above is 
legal, but the similar: 



Yl 



$3 := x ..} Y2 Y3 



is not legal because the symbol to the immediate right of the ac- 
tion code is the second vocabulary symbol, not the third one. 



4.0 Define support routines 

The support routines referenced in the action code must be 
defined before skeleton. p can be compiled. They can freely 
reference any variables, constants, types, or files declared by 
the translator-writer in the grammar. For the example, the five 
routines are: 

procedure init; 
begin 

topandstk := 0; 

toptorstk := 0; 
end; 

function popopand: integer; 
begin 

if topandstk = then begin 

writeln( 'operand stack underflow'); 
LLFatal; {terminate translation} 
end 
else begin 

popopand := opandstk[topandstk] ; 
topandstk := topandstk - 1; 
end; 
end; 

procedure pushopand(element : integer); 
begin 

if topandstk = stksize then begin 
writeln( 'operand stack overflow'); 
LLFatal; {terminate translation} 
end 
else begin 

topandstk := topandstk + 1; 
opandstk[ topandstk] := element; 
end; 
end; 

procedure popoptor(var result: char); 
begin 

if toptorstk = then begin 

writeln( 'operator stack underflow' ) ; 
LLFatal; {terminate translation} 
end 
else begin 

result := optorstk[toptorstk] ; 
toptorstk := toptorstk - 1; 
end; 
end; 



procedure pushoptor(element : char); 
begin 

if toptorstk = stksize then begin 

writeln( 'operator stack overflow'); 

LLFatal; {terminate translation} 

end 
else begin 

toptorstk := toptorstk + 1; 

optorstk[toptorstk] := element; 

end; 
end; 

These five function and procedure declarations should be placed 

in LLsup.i. 

These routines reference a procedure not previously 
described: 

LLFatal 

LLFatal is a pre-defined procedure which will terminate the 
translation after printing an appropriate message. It is used 



when a catastropic translation error occurs, such as overflowing 
optorstk. It is also called as the default error recovery when a 
syntactic error is detected by skeleton. o and no user-defined 
recovery has been specified in the grammar. You can freely call 
it within your action code. It takes no arguments. 

5.0 Lexical Analyzer 

Once the support routines are complete, the lexical analyzer 
— LLNextToken — must be constructed. The lexical analyzer 
needed for translating EXPRESSIONS has been broken down into two 
routines, LLNextToken and nextchar. The latter is called by 
LLNextToken to obtain the next character from the source text and 
to take care of bookkeeping chores such as writing the lines of 
source text out to a listing file and updating a line counter. 

Several pre-defined error processing routines will need to 
know the line number of the source text where the error occurred. 
This information must be kept in the pre-defined integer variable 
LLLineCount. Skeleton. p will initialize this counter to for 
you before parsing begins. It is the your responsibility to up- 
date it properly through LLNextToken. 

procedure nextchar; {assign next character from source 
to curchar} 
begin 

if not eof then begin 

if LastWasEoln then begin 

LLLineCount := LLLineCount+1 ; 
LastWasEoln := false; 
end; 
if eoln then 

LastWasEoln := true; 
read ( curchar ) ; 
end {if not eof} 
else 

curchar := '@' 
end; {nextchar} 



procedure LLNextToken; {get next token from candidate} 
var 

i: integer; 
begin with LLCurtok do begin 

{curchar should become the first non-blank} 
while curchar = do nextchar; 

{clear PrintValue field} 
for i := 1 to LLStringLength do 

PrintValue [i] := ' '; 
if curchar in ['0'..'9'] then begin 
{token is an integer} 
i := 1; 

Tablelndex := LLFind( 'INTEGER' , group); 
PrintValue [i] := curchar; 
attribute. operand := 

ord( curchar) - ord('O'); 
nextchar; 

while curchar in ['0'..'9'] do begin 
i := i+1; 

PrintValue [i] := curchar; 
attribute. operand := 

attribute. operand*10 + 
ord(curchar) - ord('O'); 
nextchar; 
end; 
end 
else if (curchar = '(?') and eof then begin 
PrintValue := 'end-of-f ile'; 
Tablelndex := LLFind('@', group); 
end 
else begin 

PrintValue [1] := curchar; 
attribute. operator := curchar; 
Tablelndex := LLFind( PrintValue, literal); 
nextchar; 
end; 
end; {with} 
end; {LLNextToken} 

There are a handful of simple conventions which must be followed 
in constructing LLNextToken so that it communicates with the 
parser properly. 

First, despite its appearance above LLNextToken does have a 
parameter. Because this routine must be referenced within 
skeleton. p long before the point where LLsup.i is inserted into 
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it, LLNextTokenhas a forward declaration in skeleton. p: 

procedure LLNextToken( var LLCurTok: LLTok ); 
forward; 

All direct communication between the lexical analyzer and the 
parser is through the parameter LLCurTok. The type LLTok is 
pre-defined in skeleton. p to be: 

LLTok = record 

PrintValue: LLStrings; 
attribute: LLattribute; 
Tablelndex: integer 
end; 

LLStrings is pre-defined to be: 

LLStrings = packed array [ 1 . .LLStringLength] of char; 

where LLStringLength is a pre-defined constant equal to 12. 
LLattribute is the user-declared type discussed in section 3.5. 

LLNextToken has one major function — to fill-in the three 
fields of LLCurTok. LLNextToken should assign a value to the at- 
tribute associated with the current token. The particulars of 
this assignment will vary with the declaration of LLattribute, 
the particular token encountered, and the translator being imple- 
mented. LLNextToken should assign to the PrintValue field of 
LLCurTok the string which you want to be printed when the built- 
in error-processing routines are called. For ordinary literals 
and groups, this is usually the characters of the candidate 
string. For non-printable terminals, such as an implicit end- 
of-statement marker as is found in FORTRAN, the string 'end-of- 
stmt' might be assigned to LLCurTok. PrintValue instead. 

LLNextToken must also assign a value to the "Tablelndex" 
field of the current token. Skeleton. p has an internal symbol 
table (not to be confused with any symbol table which you might 
produce for your translator) to keep information about the termi- 
nal symbols of the grammar. This table is designed to minimize 
parsing time. The table structure is hidden from you and is ir- 
relevant to what you have to write in LLNextToken. All of your 
communication with that table will be through the pre-defined 
routine "LLFind": 

function LLFind( item: LLStrings; which: LLStyle ): integer; 

Its first argument is the literal or group name which this token 
corresponds to. For literals this value normally equals 
LLCurTok. PrintValue. For groups, LLFind should be called with 
the group name rather than the literal value of the token. The 
second argument is either the enumerated constant "group" or 
"literal" depending on the token type. LLFind returns the index 
into the symbol table where that argument can be found. If the 
token cannot be found, the index value is returned, indicating 
that the token is illegal. You can process an illegal token at 
the lexical level if you prefer or pass the responsibility on to 
the parser. In any event, whether LLFind returns a positive or 
zero integer, this index should be assigned to 
LLCurTok . Table Index . 

The special case when the end of the source string is 
reached is handled quite simply. LLFind should be called with 
the first character of item equal to "@" and the remaining char- 
acters blank. "@" is a group. The value returned by LLFind 
should be assigned to LLCurTok. Tablelndex. LLCurTok. PrintValue 
could be assigned the string 'end-of-f ile' or some other ap- 
propriate string, and LLCurTok. attribute should be left unde- 
fined. 

Note that there are two user-defined variables referenced in 
nextchar. They must be declared in the grammar along with the 
other variables used for the other support routines in LLsup.i: 

%v LastWasEoln: boolean; 
curchar: char; 

In order for LLNextToken to work properly the first time it 
is called, curchar and LastWasEoln must already have a value. 
Hence, an action routine which assigns these two variables a 
value must be called before skeleton. o references LLCurTok. To 
do so a special user-defined procedure, ""LLInitialize" will al- 
ways be executed before parsing really begins. After LLInitial- 
ize has been executed, LLNextToken will also be called automati- 
cally causing LLCurTok to become defined so that parsing can be- 
gin. LLInitialize can also be used to reset the sourcefile if it 



is not that standard input, or to reset or rewrite any supplemen- 
tal files declared in the grammar. 

Since LLInitialize will automatically be called, you should 
be sure to include a declaration for it in LLsup.i, even if it 
doesn't really do anything useful in your translator. 

procedure LLInitialize; 
begin 

LastWasEoln := true; 

nextchar {must be called to ensure LLNextToken works} 
end; 

All support routines including LLNextToken are placed into 
LLsup.i. 

If you are using a true Pascal compiler such as Berkeley's 
"pc" which supports separate compilation and linkage to routines 
written in C, (as opposed to "pi" which produces P-code, not 
machine code, and hence does not support separate compilation), 
you may want to consider writing a small C program to do the ac- 
tual reading and writing and linking that with the compiled ver- 
sion of skeleton. p. Depending on the nature of the i/o, a C ver- 
sion of "nextchar" could perform significantly faster than a Pas- 
cal version. Since such a large percentage of the total time is 
spent reading and writing, this could dramatically affect the 
overall run-time of skeleton. o. Whether this particular strategy 
will, in fact, improve skeleton. o's performance depends heavily 
on the quirks of your Pascal compiler and the i/o performed in 
skeleton. o. 



6.0 Execute generate. o and compile skeleton.p 

6.1 Normal translation 

At this point all pieces necessary to construct the transla- 
tor are complete. Generate. o should now be executed redirecting 
the input from your grammar file: 

generate. o < MyFile 



Generate. o will print a few informational messages as it 
processes. In particular, it will tell you how many vocabulary 
symbols and productions are in your grammar. It has extensive 
error checking capabilities; for example, it will flag a refer- 
ence to an undeclared vocabulary symbol, a second declaration of 
the same symbol, or the appearance of an ill-formed production. 
When generate. o finishes, it will return to the shell from which 
it was called. 

At this point you should compile skeleton.p using the Pascal 
compiler : 

pi skeleton.p; mv obj skeleton. o 

All files except LLsup.i that must be included in skeleton.p will 
have been generated when you executed generate. o. Assuming there 
are no fatal error messages from the Pascal compiler, the object 
code should be an executable version of your translator. 

The Pascal compiler may issue warnings that certain pro- 
cedures which begin with "LLSkip" have not been referenced — 
LLSkipToken, LLSkipNode, and LLSkipBoth. Do not be bothered by 
these warnings. These three procedures are pre-defined for error 
processing. If you use the default error recovery, they will not 
be referenced (which should be the case for G_EXPRESSI0NS now). 
Later when you add error recovery information into your grammar, 
you will probably reference one or more of the routines, in which 
case the warnings will disappear. 

You may receive two other warnings as well which you can 
safely ignore. The compiler may warn you that fields "table" and 
"grammar" of LLgram* are not referenced. It is just a quirk of 
pi's analysis routines that it thinks these fields are never 
referenced. They, in fact, are referenced. 

If other warning or error messages appear, they probably in- 
dicate a problem with your action code, or possibly with a gram- 
mar declaration for a variable, constant, or type. Fortunately, 
the Berkeley Pascal compiler pinpoints which included file it was 
compiling when the error was detected. You should use the fol- 
lowing strategy to isolate errors produced during the compilation 
of skeleton.p: 
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File Where 
Error Occurs 

LLconst.i 

LLvar.l 

LLtype.i 

LLflle.l 

LLact.i 

LLsup.i 



Probable Problem 

illegal Zc declaration in grammar 
illegal %v declaration in grammar 
illegal %t declaration in grammar 
illegal %f declaration in grammar 
illegal action, patch, or synch code 
illegal support routine 



Errors in the action, patch, and synchronization code will show 
up as problems In the file LLact.i which was produced by 
generate *o. (Patch and synchronization code are used in error 
recovery, and have a form similar to action code. For more in- 
formation on them see section 7.2.) For convenience in discussing 
LLact.i, we will refer to any action, patch, or synchronization 
code as "embedded code". 

LLact.i is actually the declaration of procedure LLTakeAc- 
tion which structures the calls to all embedded code. LLTakeAc- 
tion has the following structure: 

procedure LLTakeAction(CaseIndex: integer); 
begin 

case Caselndex of 

1: begin embedded-code-sequence-1 end; 
2: begin embedded-code-sequence-2 end; 

n: begin embedded-code-sequence-n end; 
end; 
end; 

where the i-th embedded-code-sequence is a copy of the i-th em- 
bedded code sequence in the grammar beginning the count from the 
first production. So, for example, if the compiler reports an 
error in embedded-code-sequence-2 in LLact.i, then the erroneous 
code can be found in the 2nd embedded code sequence in your gram- 



If you discover any errors in your translator, the correc- 
tive action necessary will depend on the severity of the error. 
An error in the grammar will require you to modify it, reexecute 
generate. o, and recompile skeleton. p. However, if the grammar is 
correct, but one of the support routines or LLNextToken has a bug 
in it, then only skeleton. p needs to be recompiled after the bug 
is corrected. 

Once skeleton. p is compiled without error, you should exe- 
cute skeleton. o. The source string should come from whatever 
file you specified in LLNextToken. For our example this is the 
standard input, so we would type either: 



skeleton. o 



work interactively 



skeleton. o < MyFile — read from file 

Since, in this case, skeleton.© writes to the standard output, as 
you complete an expression and type a carriage return, the inter- 
preter will display the expression's value on the screen. An er- 
roneous expression will cause an error message to be displayed, 
and the interpreter to terminate execution. In the next section, 
you will learn how to specify any of several different error 
recovery policies instead. 

6.2 Verbose mode 

For convenience in debugging your translator, there is a 
version of the skeletal translator which includes facilities for 
tracing the parsing actions it takes in translating a candidate 
string — skel.debug.p. These trace features are not available 
in skeleton. p. Samples of the "verbose" output of s kel.de bug. o 
which has the tracing features on are given in both Appendices A 
and B. 

7.0 Error processing 

A translator constructed according to the instructions 
presented so far will process correct input properly. However, 
if a string which is not in the source language is given to it, 



the translator will simply report the error and halt. Because of 
the viable prefix property of LL(1) parsers, a syntactic error is 
detected at the leftmost position in the source string for which 
there is no legitimate continuation. In most circumstances such 
poor error recovery (i.e., quitting) is unacceptable. Zuse has a 
number of other pre-defined error recovery strategies which you 
can specify in the grammar. These fall into two major 
categories: patches and synchronizations . 



7.1 Patching errors 

When a syntactic error is discovered, there are three 
recovery strategies other than quitting which can be tried: 



easy 



skip past the current token from the source string, but con- 
tinue the parse from the same place in the parse tree. 

skip past the current node in the parse tree, (consider it 
to have been matched), but continue the parse with the same 
token in the source string. 

skip past both the current token and the current node in the 
parse tree. 

None of these may prove adequate, in which case the more sophis- 
ticated recovery strategy of synchronization must be used. How- 
ever, local patching is often sufficient. 

In order to specify a recovery strategy other than quitting, 
you must include what is called "patch" code in the grammar. A 
patch routine looks exactly like an action routine except that 
instead of beginning with "{a", it starts with "{p". 

A patch routine can follow any terminal symbol, and applies 
to the symbol which precedes it. In our example, one of the al- 
ternatives for "P" can be patched quite nicely: 

P = ( E ) {p LLSkipToken} ; 

During normal parsing, patch routines are not executed. In this 
respect they differ from action routines which are always execut- 
ed when it is their "turn" in the derivation. The parser simply 
skips over patch routines because they are not needed for normal 
processing. 

The parser can detect a syntactic error in one of two ways. 
If the next symbol in the sentential form is a terminal and the 
current token does not match it, that is an error. Similarly, if 
the next symbol is a nonterminal, but no alternative production 
for that symbol has a selection set which includes the current 
token, that is also an error. Patching addresses only the first 
type of error, synchronization addresses both. 

When the parser detects an error during the matching of a 
terminal in the sentential form against the current token in the 
source string, it checks whether there is patch code associated 
with that terminal symbol. Patch code is always associated with 
the terminal symbol it follows. In this example, patch code is 
associated with the right parenthesis since the "{p ...} code 
follows ")" in the production. 

If there is no patch code, the parser quits with a fatal er- 
ror message. On the other hand, if a patch is present, the 
parser executes the patch code. This should alter the source 
string by removing the current token, or treat the terminal in 
the sentential form as if it had been matched and advance it, or 
both. The parse then resumes. The patch code in the production 
above states that when a closing parenthesis is expected in an 
expression but none is found, then the current token should be 
skipped and the next one examined. The overall effect of this is 
to remove tokens until a right parenthesis is found in the source 
string. If the end of the source string is reached before ")", 
the translator will quit with a fatal error message. 

LLSkipBoth, LLSkipToken, and LLSkipNode are three parameter- 
less pre-defined procedures designed to facilitate patch 
recovery. They are declared in skeleton. p by: 

procedure LLSkipBoth 

procedure LLSkipToken 

procedure LLSkipNode 

LLSkipToken just removes the current token. LLSkipNode leaves 



the current token in the source string unchanged, but advances 
the pointer to the current node in the parse tree, essentially 
ignoring the node in the parse tree which did not match the 
current token. LLSkipBoth skips past both the current token and 
the current node of the parse tree. All routines cause a message 
to be printed both to LLMessageFile and to the terminal explain- 
ing the nature of the error and the recovery taken. 

LLSkipBoth can be helpful when you encounter a token which 
is often misplaced. For example, the following Pascal constant 
declarations are both incorrect: 



const 



false; 
= 3; 



(both patch and synchronization) specified in a production only 
applies if that production has been previously selected. An er- 
ror in the token used to select a production will cause error 
recovery information specified for the first vocabulary symbol on 
the right-hand side of that production to be ignored — unless 
the selection set of that production has been augmented by "any", 
"any" will cause the synchronization recovery which follows the E 
to be applicable, even if the token used for selecting from among 
the alternatives for Ax is erroneous. 

Synchronization information is not written in Pascal, but in 
a special format specifically designed to express that form of 
recovery. The general format is: 



'{s" recovery 



Pascal code "}" 



After the identifer being declared, the programmer should have 
written "-", but has written ":" and ":=" instead. These are 
likely errors, especially for a beginning programmer. Assuming 
that the original production for a constant declaration is: 



where each clause of the recovery specification, separated by 
commas, has the form: 

token "=>" integer 



ConstDcl = Ident 



Literal 



the translator-writer can perform special checks 
likely errors by replacing that production with: 



for these two 



token 



=>" 



ConstDcl ■ Ident 



{p with LLCurTok do 
if (Tablelndex 
(Tablelndex 
LLSkipBoth 
else 



LLFind(':', literal)) or 
LLFind(':=', literal)) ther 



} 



Literal 



Patches are limited because they are a highly localized 
recovery. Only that part of the source string immediately sur- 
rounding the current token is affected. Furthermore, parsing al- 
ways resumes in the sentential form where it left off before the 
error was detected. Even if an entire section of the sentential 
form has been "contaminated" by the error, it is not possible us- 
ing a patch to skip forward in the sentential form to a more ap- 
propriate point such as that corresponding to the beginning of 
the next statement. The need to synchronize with a point later 
in the sentential form motivates the recovery strategy described 
in the next section. 



7.2 Synchronization 

Synchronization is a more sophisticated recovery strategy 
which allows you to skip arbitrarily many tokens in the source 
and past arbitrarily many symbols in the sentential form before 
resuming the parse. It is needed when an error is so severe that 
local patching is inadequate and the whole "area" surrounding the 
error must be abandoned as non-repairable. 

Synchronization recovery is specified In the grammar. As 
with action and patch code, synchronization information Is sur- 
rounded by curly brackets, except that it begins with "{s". The 
productions for "Ax" can be modified from: 



Ax 



to: 
Ax = 



{a init} E {a writeln(popopand) ; } 
': ' Ax : 



= {a init;} E {s ';' => 2} 

{a writeln(popopand) ; } ';' Ax %any ; 

Although only a terminal can be associated with patch code, any 
vocabulary symbol can be associated with a synchronization 
specification by placing the specification immediately after it. 
For our example nonterminal E is associated with the synchroniza- 
tion specification. 



The Pascal code which follows the semicolon will be described 
shortly, but first the simpler form used in G_EXPRESSIONS which 
has only one clause and no Pascal code will be explained. 

Synchronization elements are just like patch code in that 
they do not affect parsing until a syntactic error is detected. 
The synchronization information is simply ignored until then. 
However, when the parser detects a syntactic error, one of 
several things can happen depending on the circumstances. If 
there is no user-defined recovery governing the parser's actions 
at this point, the parser treats the error as fatal and simply 
terminates execution. On the other hand, if the parser was at- 
tempting to match a terminal symbol against a terminal in the 
sentential form which has patch code associated with it, then 
this local recovery will be taken whether synchronization is 
specified or not. Under all other circumstances, synchronization 
recovery is activated. 

To illustrate how synchronization works, suppose you were to 
attempt to parse the expression "3-H-5", which has an extra "+". 
When the parser looks for an operand after the first "+" , it will 
find the operator "+" instead. The parse tree at this point, 
with uninteresting portions elided will be: 

Axiom 

I 



I 

{a initialize} 



l l III 

{a init} E {s ';•' => 2} {a . . } ; Ax 

I 



I 

E-list 

I 



l l l 

Asop {a .. } T 

l 



{a $0 , operator := '+'} 



The parser will have successfully expanded Asop, have executed 
the action code following it, and be attempting to expand T when 
the error is detected. The current token value is "+" but the 
selection set for the sole alternative production for T is ['(', 
INTEGER], Since T is a nonterminal, no local patch is possible. 
However, synchronization can be performed even though there is no 
synchronization specification directly following T. 



Besides including synchronization recovery, the second al- 
ternative production has been changed so that the selection set 
element "any" has been specified. It has been added to ensure 
that the second alternative production for Ax will always be 
selected whenever Ax must be expanded and the end of the source 
string has not yet been reached (the selection set of the first 
alternative is {@}). This is necessary because error recovery 



T is a descendent of E-list, which in turn is a descendent 
of E. E is followed by a synchronization element. The synchron- 
ization policy of a nonterminal is implicitly inherited by its 
descendents. Any descendent nonterminal can explicitly override 
that synchronization policy by establishing one of its own, and 
any descendent terminal can override that synchronization policy 
through patch code, but by failing to establish a recovery of its 
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own, a symbol inherits its recovery policy from its parent. 

The effect of this synchronization is to instruct the parser 
to erase that part of the parse tree hanging under the E, and to 
skip tokens in the source string until a semicolon is found. 
Failure to find a semicolon before the end of the source string 
is reached is fatal. However, if a semicolon is found, the 
parser will resynchronize the parse with the node in the parse 
tree corresponding to the second vocabulary symbol among the si- 
blings of E, since it is the E where the governing synchroniza- 
tion is located. In this case the second vocabulary symbol is 
';'. The parse then resumes as if all nonterminals to the left 
of that semicolon had been expanded and all terminals to its left 
had been matched. 

The total effect of the synchronization is to skip over to- 
kens until the end of an expression is found and to resume pars- 
ing at that point in the parse tree where the end of an expres- 
sion is expected. This decision is based on the premise that if 
an error is discovered in an expression for which no local patch 
is defined, then the best policy is to simply skip past the rest 
of that expression and resume parsing with the expression separa- 
tor. 



In the more general case there will be 
the synchronization specification: 



several clauses in 



"{s" tokenl "=>" intl 



tokenk "=>" intk "}" 



Having several clauses allows the parser to resynchronize at dif- 
ferent places depending on the sequence of tokens encountered in 
the source string. When synchronization recovery is initiated, 
the parser will skip tokens in the source string until it finds 
one which matches one of tokenl through tokenk. When it does so, 
it will use that clause for synchronization, continuing the parse 
at the point indicated by the integer in that clause. 

The advantage of being able to synchronize in different 
places becomes clear when we consider error recovery for a Pascal 
compiler. When an error occurs in a statement, the translator- 
writer may wish to skip to different points in the source string 
and parse tree depending on the circumstances. For example the 
variable declaration: 



t,3u = integer; 

contains two syntax errors. The illformed token '3u' appears 
where an identifier is required, and ' = ' is used where ':' is ex- 
pected. If the only error were the appearance of 3u, then one 
reasonable recovery would be to skip to the ' : ' . However, since 
that symbol is missing, we should skip to the ';' instead. As- 
suming the production in effect for the parsing of these type de- 
clarations originally were: 

VarStmt = IdList : TypeConstruc ';' ; 

It should become: 

VarStmt = IdList {s ' ; ' => 4, ' : ' => 2} : TypeConstruc ; 

to implement this strategy. 

Occassionally , you will not wish to synchronize on a symbol 
which occurs in the production in which the synchronization ele- 
ment appears; rather, you will want to skip past the whole 
right-hand side, as if the parser had completed the derivation of 
the entire right-hand side. To indicate this, a '*' is used in 
place of an integer in a clause of the synchronization element. 
For example, if the synchronization element of the alternative 
production for Ax were replaced by: 



An important synchronization feature is the ability to op- 
tionally include Pascal code after a semicolon in the synchroni- 
zation specification. This code is occasionally necessary in 
order to "clean up" any data structures which would otherwise be 
left in an inconsistent state by the synchronization. For exam- 
ple, if action code on the right-hand side of a production is 
skipped during resynchronization, then attributes and variables 
which that action code would have assigned values will not have 
the proper values. This Pascal code will be executed after 
determining which clause of the synchronization specification 
will be used. It can assign values, clear stacks, reset 
counters, and perform any other housekeeping chores so that when 
parsing resumes, all data structures are in a consistent state. 
Different clean-ups are possible depending on which clause is 
selected. The code can examine LLCurTok to determine which 
clause was selected and then take the appropriate action. For 
example, the synchronization specification: 

TypeDcl = 

TypelD '=' 

{s ',' => 2, ':' => 3, any => * ; 
with LLCurTok do 

if Tablelndex = LLFind( ' , ' literal) then 

... recovery appropriate for ','... 
else if Tablelndex = LLFind(':', literal) then 

... recovery appropriate for ':' ... 
else 
... other recovery ...} 
TypeDenoter; 

permits the translator to take different action when recovering 
from quite different situations: 



type 

speed : integer; 
high, low = real; 



g 123 = char; 



=> *> 



-> 2} 



then the string: 



{should be '=' — assume it is} 
{only one type identifier can be 
declared per declaration — but 
can set up symbol table to accept 
high and low anyhow} 
{perhaps this is an embedded blank 
in type identifier — don't really 
know what to do, so skip to end of 
declaration and "throw out" type 
identifier g found so far} 



There is one final embellishment on the specification of syn- 
chronization information which is often quite useful. Consider a 
production for a Pascal Program: 

Program = 

Header LabelPart ConstPart TypePart VarPart FuncProcPart 
ExecStmt . ; 

One reasonable synchronization recovery strategy is: 

Program = 
Header 

{s PROGRAM => 1, LABEL => 2, CONST => 3, TYPE => 4, 

VAR => 5, FUNCTION => 6, PROCEDURE => 6, BEGIN => 7} 
LabelPart 

{s LABEL => 2, CONST => 3, TYPE => 4, VAR => 5, 
FUNCTION => 6, PROCEDURE => 6, BEGIN => 7} 
ConstPart 

{s CONST => 3, TYPE => 4, VAR => 5, FUNCTION => 6, 
PROCEDURE => 6, BEGIN => 7} 
TypePart 

{s TYPE => 4, VAR => 5, FUNCTION =0> 6, PROCEDURE => 6, 
BEGIN => 7} 
VarPart 

{s VAR => 5, FUNCTION => 6, PROCEDURE => 6, BEGIN => 7} 
FuncProcPart 

{s FUNCTION => 6, PROCEDURE »> 6, BEGIN »> 7} 
ExecStmt 



3/4 



would cause the parser to recover by terminating normally even 
though no semicolon is present in the source. All of the chil- 
dren of Ax would be skipped. Since Ax is the rightmost child of 
Axiom, the entire parse tree would be considered generated by the 
parser at this point. Hence, the translation would terminate 
normally. Using the, original synchronization element, the parser 
would have terminated execution with a fatal error when it was 
unable to find a semicolon. 



This synchronizes the program on each major block section as 
determined by a keyword. Although this specification is ade- 
quate, it appears highly redundant. To abbreviate the specifica- 
tion of recovery information common to several vocabulary sym- 
bols, Zuse allows you to write synchronization code which Is glo- 
bal to the entire right-hand side. This code, written in the 
same syntax as other synchronization specifications, must appear 
as the first symbol on the right-hand side of the production: 
Program - 

{s PROGRAM => 1, LABEL => 2, CONST => 3, TYPE »> 4, 
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VAR -> 5, FUNCTION -> 6, PROCEDURE -> 6, BEGIN -> 7} 
Header LabelPart ConstPart TypePart VarPart FuncProcPart 
ExecStmt . ; 

The synchronization specified in this production applies to each 
vocabulary symbol with the following stipulation. Recall that it 
is illegal to attempt to synchronize to the left of the vocabu- 
lary symbol where the error is detected. Consistent with this 
view, when attempting to synchronize based on a global synchroni- 
zation, skeleton. o will ignore a synchronization clause which 
would cause it to resynchronize to the left of the current voca- 
bulary symbol. For example, the text: 

PROGRAM test (input, out put); 
LABEL 10; 
CONST 

pi : 3.14159; 
LABEL 20; 
TYPE 

speed » real; 



contains an error in the declaration of the constant pi and er- 
roneously has a second label declaration section. Assuming the 
error recovery just specified was applicable, skeleton. o would 
skip past the rest of the constant declarations, past the second 
label section , and resynchronize on the keyword TYPE. The second 
label declaration section would be skipped because when the error 
was detected, the parser would be processing ConstPart, which is 
the third vocabulary symbol on the right-hand side, but LABEL 
causes resynchronization on the second symbol. 

Of course, there is not always a single synchronization 
strategy that is appropriate for every vocabulary symbol in a 
production. To accommodate this fact, you can overide global 
synchronization by explicitly specifying either patch or another 
synchronization code after any vocabulary symbol: 

Program - 

{s PROGRAM => 1, LABEL => 2, CONST => 3, TYPE => 4, 

VAR => 5, FUNCTION => 6, PROCEDURE => 6, BEGIN => 7} 
Header LabelPart ConstPart TypePart VarPart FuncProcPart 
ExecStmt 

{s . => 8} 



If an error would occur in ExecStmt, then skeleton. o would skip 
tokens until it found a period. It would then resynchronize on 
the eighth vocabulary symbol. The recovery of all other vocabu- 
lary symbols would still be governed by the global synchroniza- 
tion specification. 
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Zuse is very easy to install if you are running Unix with the 
Berkeley Pascal compilers (pi or pc). It was designed to be 
highly portable so that if you do not have these compilers, I ex- 
pect you will still be able to compile Zuse without too much dif- 
ficulty. Every line of Zuse which is (as best as can be deter- 
mined) not standard Pascal has been marked with a comment brack- 
eted by (* .. *). All other comments use the curly bracket del- 
imiters { .. }. Hence, it should be quite easy to browse through 
the source code with a text editor and examine each non-standard 
feature. 

Zuse consists of two Pascal programs — generate, p and 
skeleton. p. Generate. p should be compiled with the resulting ob- 
ject code saved under the name generate. o (or whatever suits your 
fancy). Skeleton. p is a skeletal Pascal program which is aug- 
mented by a person writing a translator in the manner described 
in the Zuse Users' Manual. Hence, a user of Zuse will need ac- 
cess to generate. o and skeleton. p. 

To create Zuse in the current directory, just type: 

tar xv 

pi [options] generate. p 

mv obj generate. o 



where [options] are whatever compiler options you desire. You 
may need to qualify the tar command with the tape drive number 
you mount the distribution tape on. When you execute tar, a 
number of files other than generate. p and skeleton. p will be 
placed in your current directory. In particular, you will also 
find: 

skel. debug. p — debugging version of skeleton. p 

Rawlnstall — pre-nroff form of this document 

Install — post-nroff form of this document 

RawUser — pre-nroff form of Users' Manual 

UserManual — post-nroff form of Users' Manual 

FortGrammar — grammar for structured FORTRAN preprocessor 

FortLLsup.i — support routines for FORTRAN preprocessor 

ExpGrammar — grammar for arithmetic expression evaluator 

ExpLLsup.i — support routines for expression evaluator 

The pre-nroff documents do not use either the -me or the -ms 
nroff macro libraries. They are entirely self-contained, so you 
can recreate either document by typing: 

nroff Rawlnstall > Mylnstall 
nroff RawUser > MyUser 

To create the FORTRAN preprocessor under the name Struct. o, just 
type : 

generate. o < FortGrammar 
cp FortLLsup.i LLsup.i 
pi [options] skeleton. p 
mv obj Struct. o 

To create the expression evaluator under the name express. o, just 
type: 

generate. o < ExpGrammar 
Cp ExpLLsup.i LLsup.i 
pi [options] skeleton. p 
mv obj express. o 

A word of caution is necessary. Whenever you run generate.o, the 
file LLgram is created. It contains a crunched version of the 
grammar input to generate.o and is peculiar to the particular 
translator being created with Zuse. When a translator created 
with Zuse (such as Struct. o or express. o) is executed, it reads 
in LLgram in order to initialize its parser. Hence, LLgram must 
be in the current directory. This also means that you cannot 
readily have more than one translator produced by Zuse in the 
same directory, since each one will require its own version of 
LLgram. For the classroom environment for which Zuse was 
developed, this is no problem. However, for more varied applica- 
tions, this restriction can be Inconvenient. With a modest bit 
of surgery, this restriction is readily removed. Rename LLgram 
to whatever file name is convenient after running generate.o, and 
change the line: 

reset(LLgram); 

in skeleton. p to 

reset(LLgram, YourName); 

where YourName is the Unix file name where you moved LLgram. 

1. program skeleton( input .output , LLgram 

2. #include 'LLfile.i' 

3. (* UNIX *) 

4. ); 

5. {skeletal compiler to parse a candidate string} 
6. 

7. { May 8, 1981 

8. Version: 1.0 

9. Author: Arthur Pyster 

10. Copyright (c): The Regents of the University of California 

11. Purpose: This program is a skeletal compiler which is 

12. fleshed out by the inclusion of a file supplied 

13. by the user: 
14. 

15. LLsup - support routines called directly 

16. or indirectly as action routines 

17. including LLNextToken 
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18. 
19. 
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52. 
53. 
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56. 
57. 
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63. 
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108. 
109. 
110. 
111. 
112. 
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114. 
115. 
116. 
117. 
118. 
119. 



and 5 files provided by "generate", the 
parser generator: 

LLfile - file dels specified in grammar 

LLvar - var dels required for action 
routines 

LLconst - const dels specified in 

grammar and misc. constants 

LLtype - type dels specified in grammar 

LLact - LLTakeAction procedure which 

calls action routines as dictated 
by grammar rules 

The file LLgram, produced by gene rate. o, must be read in. 
It contains an encoded form of the grammar, error data, and the 
symbol table. 

Error messages are written to the standard output unit.} 



label 1000; 
const 

LLMaxStack =» 200; {max number of sentential form elements in parse 
tree at any one time.} 

# include 'LLconst.i' 
(* UNIX *) 



LLStrings ■ packed array [ 1. .LLStringLength] of char; 



#include ' LLtype. i' 

(* UNIX *) 

LLGramEntry - 

record case boolean of 

true: (table: LLStrings); 

false: (grammar: integer); 
end; 

LLTok - 
record 

PrintValue: LLStrings; {the literal token value} 
Tablelndex: integer; {index where token is In symbol table} 
attribute: LLattribute; 

{value associated with the token by 
LLNextToken — can be used by an action routine} 
end ; 

LLStyle ■ (literal, nonterminal, group, action, patch); 

{literal: a terminal which stands for itself.} 

{group: a terminal which is a lexical group of LLStrings, 

but syntactically just a single symbol} 
{action: an action routine call} 
{patch: an action routine to patch syntactic errors} 

LLRight - 
record 

Caselndex: integer; 
synchindex: integer; 
WhlchChild: integer; 
case kind: LLStyle of 
action, patch: (); 
nonterminal: (ProdStart: integer); 
literal, group: (Tablelndex: integer); 
end; 



LLSentential » 
record 

LastChild: boolean; 

Top: integer; 

parent: integer; 

attribute: LLattribute; 

data: LLRight; 
end; 



{is this the rightmost child?} 

{point to LastChild} 

{ptr to parent of this node} 



var 

// include 'LLvar. i' 

(* UNIX *) 
{var dels produced by parser generator} 
LLadvance: boolean; {advance LLSentPtr to next node?} 
LLStartTime: real; {clock time at start of compilation} 
LLLocEOS: integer; {location of end-of-source in SymbolTable} 
LLSentPtr: integer; {sentential form element currently being processed} 
LLLineCount: integer; {line number of source text} 

LLgram: file of LLGramEntry; {where grammar is stored} 
LLCurTok: LLTok; {the current token} 

LLSymbolTable: array [ 1 . .LLTableSize] of 
record 

key: LLStrings; 
kind: LLStyle 
end; 
LLStack: array [ 1 . .LLMaxStack] of LLSentential; {stack which represents 

the parse tree} 
LLTop; integer; {top of stack pointer} 
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procedure LLNextToken( var LLCurTok: LLTok ); forward; 



function LLFind( item: LLStrings; which: LLStyle ): integer; 

{Find item in symbol table — return index or if not found. 
Assumes symbol table is sorted in ascending order.} 
label 10; 
var 

low, midpoint, high: integer; 
begin 

LLFind := 0; {assume failure} 
low := 1; 

high := LLTableSize; 

if (item >= LLSymbolTable [low] .key) and 
(item <= LLSymbolTable [high] .key) then 
while low < high do with LLSymbolTable [low] do begin 
if key = item then begin 
if kind = which then 

LLFind := low; 
goto 10 
end 
else begin 

midpoint := (high+low+1) div 2; 

if LLSymbolTable [midpoint] .key < item then 

low := midpoint 
else if LLSymbolTable [midpoint] .key > item then 

high := midpoint-1 
else if LLSymbolTable [midpoint] .kind = which then begin 
LLFind := midpoint; 
goto 10 
end 
else {not in table} 

goto 10 
end; 
end; 
10: {emergency exit} 
end; {LLFind} 



procedure LLPrtString( str: LLStrings); 

{print non-blank, prefix of str} 
label 10; 
var 

temp: char; 
i: integer; 
begin 

write(""); 

for 1 :■ 1 to LLStringLength do 
if str[i] - ' ' then 

goto 10 
else begin 

temp :- str[i]; 
write(temp); 
end; 
10: 

write(""); 
end; {LLPrtString} 



{print header message} 



procedure LLHeader; 
var 

i: integer; 

tempLLCurTok : LLStrings; 
begin 

for i :- 1 to LLStringLength do 

tempLLCurTok [i] :- ' ' ; 
if LLCurTok. Tablelndex *• LLLocEOS then begin 

tempLLCurTok [ 1 ] :« 'e'; tempLLCurTok [2] :- 'o'; 
tempLLCurTok [3] :- 'f; 
end 
else if LLCurTok. PrintValue[l] in [' '..'~'] then (* ASCII *) 

tempLLCurTok :» LLCurTok. PrintValue; 
if tempLLCurTok[l] in ['! %.'""] then (* ASCII *) 

LLPrtString( tempLLCurTok) 
else 

write( 'Unprintable token beginning with ', 
'ord: ', ord(tempLLCurTok[l]) :3); 
end; {LLHeader} 



{remove current token} 



procedure LLSkipToken: 
begin 

LLadvance :=» false; 

write(LLLineCount:3, ' — '); 

LLHeader; 

writeln( ' is skipped.'); 

LLNextToken( LLCurTok ); 
end; {LLSkipToken} 



procedure LLSkipNode; {skip over sentential form node leaving current 

token as is} 
begin 

write(LLLineCount:3, ' — '); 

LLPrtString(LLSymbolTable [LLStack [LLSentPtr]. data. Tablelndex] .key); 

writeC inserted before '); 

LLHeader; 

writeln; 

LLSentPtr :=■ LLSentPtr +1; 
end; {LLSkipNode} 
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procedure LLSkipBoth; {skip over both sentential form node and current 
token, used when replacement is assumed to be 
correct, and attribute of replacement does not need 
to be set; otherwise use LLReplace} 
begin 

write(LLLineCount:3, ' — '); 
LLHeader ; 

write( ' replaced by ' ); 

LLPrtString(LLSymbolTable[LLStack[LLSentPtr] . data. Tablelndex] .key); 
writeln; 

LLSentPtr :« LLSentPtr + 1; 
LLNextToken(LLCurTok) ; 
end; 



procedure LLFatal; {to recover from syntactic error, terminate compilation} 
begin 

write(LLLineCount:3, ' — '); 

LLHeader; 

writelnC found. Translation terminated.'); 

goto 1000; 



end; {LLFatal} 



# include 'LLsup.i' 
(* UNIX *) 



# include 'LLact.i' 

(* UNIX *) 



{supporting routines} 



{action code produced by parser generator} 



procedure LLMain; 
const 

LocOfNull » 0; 



{location of null string in symbol table} 



type 

intset » set of 1 . . LLTableSize; 

synchtype » 

record 

token: integer; {index to Table entry for token} 
sent: integer; {how far in LLSentential form to goto} 

end; 



prod - 
record 

lhs: integer; {Tablelndex of lhs} 

rhs: integer; {index into RhsArray where rhs begins} 

cardrhs: integer; 

select: intset; 

cardsel: integer; 
end; 



ThisRhs: integer; {index into RhsArray} 

RhsArray: array [ 1. .LLRhsSize] of LLRight; {rhs elements of productions} 

synchdata: array [0. .LLSynchSize] of synchtype; 

axiom: integer; {pointer to first production whose lhs is the axiom} 

productions: array [1 .. LLProdSize] of prod; 

procedure readgram; {read grammar from disk} 
var 

i: integer; 



procedure BuildRight(whichprod: integer); {establish contents of rhs} 
var 

ChlldCount: integer; {which # child in rhs is this?} 

i: integer; 

temp: integer; 

begin with productions [whichprod] do begin 
rhs :» ThisRhs+1; 
ChildCount :- 0; 
for i :» ThlsRhs+1 to ThisRhs+cardrhs do 

if i O LLRhsSize then with RhsArray [i] do begin 
ThisRhs := ThisRhs+1; 
get(LLgram); 

temp := LLgram*. grammar; {the type of symbol} 
get(LLgram); {info for that particular symbol type} 
case chr(temp) of 
'1': begin 

ChildCount :» ChildCount+1; 
WhichChild :» ChildCount; 
kind :- literal; 
Tablelndex := LLgr am". grammar; 
get (LLgram); 

Case Index :=* LLgram*. grammar; 
get(LLgram); 

synchindex :- LLgram*. grammar; 
end; 
'a' : begin 

kind := action; 
Caselndex :» LLgram* .grammar; 
end; 
'n' : begin 

ChildCount := ChildCount+1 ; 
WhichChild := ChildCount; 
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.grammar; 



:- ChildCount+1; 
:- ChildCount; 



.grammar; 



kind :- nonterminal; 

ProdStart :- LLgram* 

get(LLgram); 

Caselndex :■ LLgram*. grammar; 

get (LLgram); 

synchindex :- LLgram*. grammar; 

end ; 
'g': begin 

ChildCount 

WhichChild 

kind :» group; 

Tablelndex :» LLgram 

get(LLgram); 

Caselndex :- LLgram*. grammar; 

get (LLgram); 

synchindex :- LLgram*. grammar; 

end; 
'p': begin 

kind :- patch; 

Caselndex :- LLgram". grammar; 

end; 
end; {case} 
end {with RhsArray} 
else begin {grammar in LLgram is screwed up} 

writeln( 'Catastrophic error — The grammar used to '); 
writeln( 'generate this compiler probably had an error.') 
writelnC 'Check to make sure that "generate. o" did not ') 
writelnC 'produce any error messages when it processed ') 
writelnC 'your grammar.'); 
goto 1000 
end; 

end; {with productions} 
end; {BuildRight} 



procedure BuildSelectCwhichprod: integer); {build selection set} 
var 

i: integer; {loop counter} 

Tablelndex: integer; {where in Table can element be found?} 
begin with productions [whichprod] do begin 
select :« []; 

for 1 :■ 1 to cardsel do begin 
get C LLgram); 

Tablelndex :- LLgram*. grammar; 
select :=■ select + [Tablelndex]; 
end; {for i} 
end; {with gram} 
end; {BuildSelect} 



begin {readgram} 

{read in symbol table} 
reset (LLgram); 
if LLTableSize > then begin 

LLSymbolTable [ 1 ] .key :» LLgram*. table; 

get(LLgram); 

if LLgram* . table [ 1 ] - 'g' then 

LLSymbolTable [ 1 ] .kind :- group 
else 

LLSymbolTable [1]. kind :- literal; 
end; 
for i :• 2 to LLTableSize do begin 
getCLLgram); 

LLSymbolTable [i] .key :» LLgram*. table; 
get (LLgram); 
if LLgram*. table[l] » 'g' then 

LLSymbolTable [i] .kind :» group 
else 

LLSymbolTable [i] .kind := literal; 
end; {for 1} 

{read in grammar} 
ThisRhs :■ 0; 
get (LLgram); 

axiom :* LLgram*. grammar; 
for i :■ 1 to LLProdSize do with productions [i] do begin 

get (LLgram); lhs := LLgram*. grammar; 

get(LLgram); cardrhs := LLgram*. grammar; 

BuildRight(i); 

get (LLgram); cardsel :* LLgram*. grammar; 

BuildSelect(i); 

end; {with} 

{now read in synchronization info} 
for i :- 1 to LLSynchSize do begin 

get (LLgram); 

synchdata [i] .token := LLgram*. grammar; {LLSymbolTable location} 

get (LLgram); 

synchdata[i] .sent := LLgram*. grammar; {where do I skip to?} 

end; { for i} 
end; {readgram} 



procedure parse; {parse the candidate} 
var 

temp: LLStrings; 

LocOfAny: integer; {location of "any" in LLSymbolTable} 

i: integer; {loop counter} 

procedure erase; 

{has rhs of prod has been matched? if so then erase rhs} 
label 10; 
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426. 


begin {only erase If at farthest point to the right in a production} 


527. 


427. 


if LLStack [LLSentPtr] .LastChild then begin 


528. 


428. 


while LLStack [LLSentPtr] .LastChild do begin {erase rhs} 


529. 


429. 


LLSentPtr := LLStack[LLSentPtr] .parent; 


530. 


430. 


if LLSentPtr * then begin {stack is empty} 


531. 


431. 


LLTop :=* 0; 


532. 


432. 


LLadvance :« false; {don't try to advance beyond axiom} 


533, 


433. 


goto 10; 


534. 


434. 


end; 


535. 


435. 


end; 


536. 


436, 


LLTop := LLStack[LLSentPtr] .Top; {set LLTop to be the LastChild 


537. 


437. 


of current rhs} 


538. 


438. 


10: 


539. 


439. 


end; 


540. 


440. 


end; {erase} 


541. 


441. 




542. 


442. 




543. 


443. 


procedure testsynch; forward; 


544. 


444. 




545. 


445. 


procedure expand; {expand nonterminal in sentential form} 


546. 


446. 


var 


547. 


447. 


i: integer; {loop counter} 


548. 


448. 


where: integer; {production being examined} 


549. 


449. 


OldTop: integer; {top of stack ptr before expansion} 


550. 


450. 




551. 


451. 


function match (sent index: Integer): integer; 


552. 


452. 


{does a production whose lhs is sentindex and whose 


553. 


453. 


selection set includes token exist? 


554. 


454. 


If so, return index to that production as value of match; 


555. 


455. 


otherwise, set match to 0.} 


556. 


456. 




557. 


457. 


label 10; 


558. 


458. 


var 


559. 


459. 


i: integer; {loop counter} 


560. 


460. 


begin 


561. 


461. 


match :» 0; {assume failure and reset if successful} 


562. 


462. 


for i :» sentindex to LLProdSlze do with productions [i] do 


563. 


463. 


if lhs » sentindex then {production has proper lhs} 


564, 


464. 


if (LLCurTok.Tablelndex in select) or (LocOfAny in select) then 


565. 


465. 


begin 


566. 


466. 


match :«= i; 


567. 


467. 


goto 10; 


568. 


468, 


end {if LLCurTok} 


569. 


469. 


else 


570. 


470. 


else 


571. 


471. 


goto 10; 


572. 


472. 


10: {emergency exit point} 


573. 


473. 


end; {match} 


574. 


474 f 




575. 


475. 




576, 


476. 


begin {expand} 


577. 


477. 


where :- match(LLStack[LLSentPtr] .data.ProdStart); 


578. 


478. 


if where <> then with productions [where] do 


579. 


479, 


{rhs of new production will be placed in list} 


580, 


480. 


if Cardrhs > then begin 


581. 


481. 


LLadvance :- false; 


582. 


482. 


OldTop :» LLTop; 


583. 


483. 


if LLTop + cardrhs > LLMaxStack then begin {overflow} 


584. 


484. 


writelnC Internal stack overflow. Recompile skeleton after', 


585. 


485. 


' increasing constant LLMaxStack'); 


586. 


486. 


LLFatal; 


587. 


487. 


end; 


588. 


488. 


for i := 1 to cardrhs do begin 


589. 


489. 


LLTop :* LLTop +1; 


590. 


490. 


with LLStack[ LLTop] do begin 


591. 


491. 


parent :« LLSentPtr; 


592. 


492, 


{put data into children from the selected production} 


593. 


493. 


data :* RhsArray[rhs-fi-l] ; 


594. 


494. 


LastChild : = false; 


595. 


495. 


case data. kind of 


596. 


496. 


action, patch, literal, group:; 


597. 


497. 


nonterminal: 


598. 


498. 


Top : = OldTop + cardrhs; 


599. 


499. 


end; {case} 


600, 


500. 


end; {with LLStack [LLTop] } 


601. 


501. 


end; {for 1} 


602. 


502, 


{mark rightmost child as the last} 


603. 


503. 


LLStack [LLTop] .LastChild := true; 


604. 


504, 


{move LLSentPtr to the first new child} 


605. 


505. 


LLSentPtr :*= OldTop +1; 


606. 


506. 


end {if} 


607. 


507. 


else 


608. 


508. 


else 


609. 


509. 


testsynch; 


610. 


510. 


end; {expand} 


611. 


511. 




612. 


512. 




613. 


513. 


procedure testsynch; 


614. 


514. 




615. 


515. 




616. 


516. 


procedure synchronize; 


617. 


517. 


{synchronize token and LLSentential form to recover from syntactic 


618. 




error} 


619. 


518. 


. label 10; 


620. 


519. 


, var 


621. 


520, 


OldCurToklndex: integer; 


622. 


521. 


i: integer; 


623. 


522. 


temp: LLStringa; 


624. 


523. 


LocOfAny: integer; 


625. 


524. 


. begin 


626. 


525. 


write(LLLineCount:3, ' — '); 


627. 


526. 


LLHeader; 


628. 



writelnC unexpectedly encountered.'); 

OldCurToklndex :- LLCurTok.Tablelndex; 

for i :■ 1 to LLStringLength do temp[i] :- ' '; 

temp[ 1] :- 'a'; temp[2] :- 'n'; temp[3] :- 'y'; 

LocOfAny :» LLFind(temp, group); 

repeat 

i := LLStack [LLSentPtr] .data.synchindex; 

while 8ynchdata[i] .sent <> do begin with synchdata[i] do 

if ((LLCurTok.Tablelndex ■ token) or (token » LocOfAny)) and 
(LLStack[LLSentPtr].data.WhichChild <« sent) then begin 
if LLCurTok.Tablelndex » LLLocEOS then begin 
writelnC Translation terminated.'); 
goto 1000; 
end; 
if LLCurTok.Tablelndex <> OldCurToklndex then begin 
writeC Skipping t,o '); 
LLPrtString(LLCurTok.PrintValue); 
writelnC in line ', LLLineCount;3); 
end; 
if LLStack[LLSentPtr].data.CaseIndex <> then begin 
{execute code after ";"} 
LLTakeAction( LLStack [LLSentPtr] .data.Caselndex) ; 
end; 
if sent <> maxint then begin {skip to correct symbol in rhs} 
while LLStack[LLSentPtr].data,WhichChild <> sent do 

LLSentPtr :» LLSentPtr + 1; 
LLadvance :» false; 
end {if sent} 
else begin {skip to rightmost node and signal reduction} 
while not LLStack [LLSentPtr] .LastChild do 

LLSentPtr :« LLSentPtr + 1; 
end; 
goto 10; 
end; {then} 
i :» i+1; 
end; {while} 
if LLCurTok.Tablelndex <> LLLocEOS then 

LLNextToken(LLCurTok) 
else begin 

writelnC Translation terminated.'); 
goto 1000; 
end 
until false; 

10: {exit point for loop} 
end; {synchronize} 



begin {testsynch} 

while LLStack [LLSentPtr] .data.synchindex ■ do {no synch info there} 
if LLStack [LLSentPtr] .parent <> then {there really is a parent} 

LLSentPtr ;* LLStack [LLSentPtr] .parent 
else 

LLFatal; 
synchronize; 
end; {testsynch} 



begin {parse} 

LLSentPtr :■ 1; {initialize sentform to be axiom} 

LLTop :- 1; 

with LLStack [LLSentPtr], data do begin 

ProdStart :» axiom; 

LastChild :- true; 

kind :« nonterminal; 

synchindex :« 0; 

end; 

{find location of 'any' in LLSymbolTable} 
for 1 :« 4 to LLStringLength do 

temp[i] :- ' '; 
temp[l] :« 'a'; temp[2] :- 'n'; temp[3] :■ 'y'; 
LocOfAny :- LLFind(temp, group); 

{find location of end~of-*source represented by 
"@" in LLSymbolTable} 
tempi 1] :- '@'; temp[2] ;- ' '; temp[3] :- ' '; 
LLLocEOS :■ LLFind(temp, group); 

LLLineCount :- 0; 

LLInitialize; 

LLNextToken(LLCurTok); {call lexical analyzer the first time} 

while LLTop <> do begin {derivation isn't finished} 

LLadvance :» true; {presume LLSentPtr advanced after iteration} 
with LLStack[LLSentPtr] , data do begin 
case kind of 

group, literal: begin 

if Tablelndex - LLCurTok.Tablelndex then begin 
attribute ;» LLCurTok. at tribute; 
LLNextToken(LLCurTok) ; 
end {else if} 
else if Tablelndex » LocOfNull then begin 

{do nothing} end 
else if not. LLStack [LLSentPtr] .LastChild then 

if LLStack [LLSentPtr + 1]. data. kind - patch then 

LLTakeActlon(LLStack[LLSentPtr +1] .data.Caselndex) 
else testsynch 
else testsynch; 
end; {group, literal} 
nonterminal: expand; 

action: LLTakeAction(LLStack[LLSentPtr] .data.Caselndex); 
patch: ; 
end; {case} 
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end; {with} 
if LLadvance then begin 

{Finished with current LLStack[LLSentPtr] . 
Move on to next node in tree} 
erase; 

LLSentPtr :- LLSentPtr + 1; 
end; 
end; {while} 
if LLCurTok. Table Index <> LLLocEOS then LLFatal; 

{only matched against part of candidate, which is not a sentence, 
terminate parsing action.} 
end; {parse} 



begin {LLMain} 

readgram; {get the grammar from the user.} 

parse; 
end; {LLMain} 



begin {main program} 

LLStartTime :- clock; (* UNIX *) 

LLMain; 
1000: 

writeln; 

writeln('**** End of translation. 
' seconds CPU time ****'); 
end. 



(clock-LLStartTime)/1000.0:5:l, 
* UNIX *) 
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program generate (input, output, LLgram, ConstFile , VarFile, 
ActFile, TypeFile, FileFile, LLselect); 

{ May 8, 1981 
Version: 1.0 
Author: Arthur Pyster 

Copyright (c): The Regents of the University of California 
Purpose: Accept the specification of a context-free translation 

grammar from standard input file and output either 

6 or 7 files: 

LLgram - a processed form of the grammar which 

will be read by SKELETON 
LLvar - Pascal var declarations which will be 

included in SKELETON. 
LLconst - Pascal constant declarations which will 

be included in SKELETON. 
LLtype - Pascal type declarations which will be 

Included in SKELETON. 
LLfile - Pascal file declarations for program 

statement which will be included in 

SKELETON. 
LLact - The TAKEACT procedure, included in 

SKELETON, which calls action 

code as dictated by the grammar. 
LLselect - On request (Zs in grammar), formatted 

selection sets. } 

label 1000; {emergency exit for unrecoverable error} 
const 

StringSize - 12; 

ProdSize - 160; 

SynchSize - 40; 

RhsSlze - 330; 

TableSize - 135; 



{max length of vocabulary symbols} 

{max number of productions} 

{max number of synchronization elements} 

{max number of rhs elements of productions} 

{max number of nonterminals, literals, and groups} 



EndOf Source - '@'; {end of candidate marker} 

type 

setofchar ■ set of char; 

{indicates current knowledge of whether production or symbol 
is nullable} 
nulltypes » (notsure, never, null); 
intset - set of 1.. TableSize; 
strings - packed array [1. .StringSize] of char; 
nonneg * 0..maxint; {non-negative integers} 
positive « L.maxint; {positive integers} 
synchtype - {synchronization info} 
packed record 

Table Index: integer; {which literal or group?} 
sent: nonneg; {where do we go in sentential form} 
end; 
style * (action, group, literal, nonterminal, patch); 

{literal: a terminal which stands for itself, 
group: a terminal which is a lexical group of strings, 

but syntactically just a single symbol, 
action: action code 
patch: action code called to repair a syntax error} 

RhsElement - {info about symbol of grammar} 
record 

Synchlndex: nonneg; {for vocabulary symbols points to place 
in syncharray where synch data about this symbol is 
located; not used for others} 
CaseSelect: nonneg; 

{for vocabulary symbols this is the synch code LLact 
index; for action and patch this Is the LLact index} 
case kind: style of 

nonterminal, literal, group: (Tablelndex: nonneg; 
WhichVocabSymbol : nonneg ) ; 

{index to symbol table entry and relative count of 
vocab symbols on rhs of production} 
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end; 



action, patch: () 



prod - {a production} 

record 

line: integer; {line number where production begins} 

lhs: integer; {index to SymbolTable entry for lhs of prod} 

rhs: nonneg; {index into RhsArray} 

CardRhs: 0..RhsSize; {number of rhs elements} 

select: intset; {selection set elements} 

resolve: intset; {elements to be forced into selection 

set by user directive} 
CardSel: 0.. TableSize; {number of selection set elements} 
nullable: nulltypes; {is production nullable?} 

end; 

symbol - 
record 

value: strings; 
ProdStart: nonneg; 
case kind: style of 

nonterminal: (nullable: nulltypes); 
literal, group, action, patch: () 
end; 

GramEntry - 

record case boolean of 

true: (table: strings); 

false: (grammar: integer); 
end; 



PrintSelect: boolean; {print selection sets of productions?} 

ErrorFree: boolean; {any error in grammar?} 

axiom: nonneg; 

SymbolTable: packed array[l. .TableSize] of symbol; 

RhsArray: packed array [L.RhsSize] of RhsElement; 

CardSymbol: nonneg; {number of entries in SymbolTable} 

CardSynch: nonneg; {current place in SynchData array being addressed} 

production: packed array [1* .ProdSize] of prod; 

ThisRhs: nonneg; {number of rhs elements in all prods} 

CardProd: nonneg; {number of productions} 

AllBlanks: strings; {StringSize blanks} 

eolninput: boolean; {eoln( input) ?} 

i: integer; {loop counter} 

spacers: setofchar; {blank and tab chars} 

linecount: nonneg; {how many lines of grammar have been read} 

LLselect: file of char; {where selection sets are 
printed on request (Zs in grammar)} 

LLgram: file of GramEntry; {where compact form of grammar is kept} 
{where file dels are stored} 
{where action routines are stored} 
{where grammar defined constants for 

Inclusion in SKELETON go} 
{where grammar defined vars for 

inclusion in SKELETON go} 
{where grammar defined types for 

inclusion in SKELETON go} 
{case number of next action routine} 

SynchData: packed array[l. .SynchSize] of synchtype; 
{where synchronization data is stored until 
written to LLgram at the end of grammar processing} 



FileFile: file of char 
ActFile: file of char; 
ConstFile: file of char: 

VarFile: file of char; 

TypeFile: file of char; 

nextact: integer; 



procedure SortTable; {sort the symbol table into ascending order by 

value field.} 
label 10; 
var 

i,j: Integer; 
ChangeMade: boolean; 
temp: symbol; 
begin 

for i :- 1 to CardSymbol-1 do begin 
ChangeMade :- false; 
for j :- 1 to CardSymbol-1 do 

if SymbolTable [j] .value > SymbolTable [j+1] .value then begin 
{exchange} 
ChangeMade :- true; 
temp :- SymbolTable [ j ] ; 
SymbolTable [j] :- SymbolTable [ j+1] ; 
SymbolTable [j+1] :- temp; 
if axiom - j then axiom :•» j+1 
else if axiom » j+1 then axiom :■ j; 
end; 
if not ChangeMade then goto 10 
end; 
10: 
end; 

function 0rderedFind( newvalue : strings): nonneg; 

{Find location of newvalue in SymbolTable. 
Return index if found; otherwise, return 0. 
Assumes table is sorted in increasing order.} 
label 10; 
var 

low, midpoint, high: integer; 
begin 

OrderedFind := 0; {presume failure} 

low := 1; 

high :» CardSymbol; 

if (newvalue <= SymbolTable [high] .value) and 
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(newvalue >« SymbolTable [ low] .value) then 
while low < high do 

if SymbolTable [low] .value ■ newvalue then begin 
OrderedFind :» low; 
goto 10 
end 
else begin 

midpoint :» (low+high+1) div 2; 

with SymbolTable [midpoint] do 

if value > newvalue then 

high i" midpoint-1 
else if value < newvalue then 

low :» midpoint 
else begin {value * newvalue} 
OrderedFind :» midpoint; 
goto 10 
end 
end; 



end; 



function find( newvalue: strings): nonneg; 

{find location of newvalue in SymbolTable. 
Return index if found; otherwise, return 0} 
label 10; 
var 

1: positive; 
begin 

find :» 0; {presume it is not found} 
for i := 1 to CardSymbol do 

if SymbolTable [i] .value » newvalue then begin 
find := i; 
goto 10; 
end; 
10: 
end; {find} 



function PrintString( s: strings ): char; 

{print s to LLselect} 
label 10; 
var 

i: positive; 
begin 

PrintString :- ' '; 
for i := 1 to StringSize do begin 
if s[i] * ' ' then 

goto 10; 
write(LLselect, s[i]); 
end; 
10: 
end; {PrintString} 

procedure insert( var newvalue: strings; 
newkind: style); 
{insert entry into SymbolTable} 
begin 

CardSymbol :« CardSymbol+1; 

if CardSymbol <= TableSize then 

with SymbolTable [CardSymbol] do begin 
value := newvalue; 
ProdStart :- 0; 
kind :■ newkind; 
end {with SymbolTable} 
else begin 

writeln( 'symbol table overflow — recompile "generate"'); 
writeln( 'after Increasing the constant "TableSize"'); 
goto 1000; 
end; 
end; {insert} 



procedure DoGrammar; {get the grammar from the user} 
const 

LongStringSize = 120; 
var 

CurLine: array[ 1 . .LongStringSize] of char; 

NextChar: char; {next character in line from input} 

ch: char; {current character of line from input} 

i: nonneg; {loop counter} 

LlneLength: integer; 

LineMarker: integer; 



procedure readchar; 
var 

tmp: char; 
begin 

if LineMarker >= LineLength then begin 
if eof(input) then begin 

writeln(linecount : 3, ' — unexpected end of input'); 
goto 1000; {emergency exit} 
end; 
LineLength := 0; 

while not eoln(input) do begin {read in line} 
LineLength :* LineLength+1 ; 
read( tmp) ; 

{only fill up through LongStringSize-2 chars since 
last two slots are filled with blanks later} 
if LineLength <= LongStringSize - 2 then 
CurLine [LineLength] :» tmp 
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else if LineLength » LongStringSize - 1 then 

writeln(linecount: 3, ' --— line longer than ', 

(LongStringSize-2) : 3, ' characters. Rest is ignored.'); 
end; {while} 
readln; 
if LineLength > LongStringSize-2 then {reset it} 

LineLength := LongStringSize-1 
else 

LineLength :» LineLength+1; {count eoln in line} 
CurLine [LineLength] :« ' '; {make eoln a blank} 
CurLine [LineLength+1] :=»''; {make NextChar of last char a blank} 
LineMarker := 0; 
linecount :*= linecount+1; 
end; 
LineMarker := LineMarker+1; 
ch :« CurLine [LineMarker] ; 
NextChar := CurLine [ LineMarker+1 ] ; 
if LineMarker=LineLength then 

eolninput := true 
else 

eolninput := false; 
end; {readchar} 



function printable( s: strings ): char; 

{print s if printable; otherwise print ord(s)} 
label 10; 
var 

i: positive; 
begin 

printable := ' '; 
write(linecount:3, ' — "'); 
for i := 1 to StringSize do 
if s[i] = ' ' then 

goto 10 
else if s[i] in ['!'.. ""] then write(s[i]) (* ASCII *) 
else begin 

write('ord: ', ord(s[i]): 3); 
goto 10 
end; 
10: write(""); 
end; {printable} 



procedure fillid(var id: strings; {build an id from Input} 

block: setofchar); 
var 

i: 0..maxint; {number of chars in id} 
quoted: boolean; {is the id surrounded by quotes?} 
begin 

id :- AllBlanks; 
i :- 0; 

if ch ■ "" then begin {id is surrounded by quotes — just ignore them} 
readchar; {skip past beginning quote} 
quoted :» true 
end 
else 

quoted :=» false; 
while ((not quoted) and (not (ch in block))) or 
(quoted and (ch <> "")) do begin 
i :- i + 1; 
if i - StringSize+1 then begin 

writeln(linecount:3, ' — symbol beginning with ', 

id, ' exceeds maximum permissible length of '); 
writelnC ', StringSize :2, '. Only first ', StringSize: 2, 

' characters examined.' ); 
end 
else if i <» StringSize then 

ld[i] :» ch; 
readchar; 
end; 
if quoted then {skip past closing quote} 
readchar; 
end; {flllid} 



procedure skipspace; {skip comments, spaces and tabs} 
begin 
repeat 

while ch in spacers do readchar; 

while (ch » '(') and (NextChar - '*') do begin {skip comments} 

readchar; readchar; {skip past '(' and '*'} 

while (ch <> '*') or (NextChar <> ')') do readchar; 

readchar; readchar; 

end 
until not (ch in spacers); 
end; {skipspace} 



procedure declarations; {process the declarations} 

{procedure reads grammar defn from first char up through 
and including XX. ch will equal char following XX when 
procedure terminates.} 
var 

temp: strings; 

selector: char; {second character of del — 

specifies type of declaration} 
next: strings; {next token in line} 
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function firstdcl( candidate: strings ): boolean; 

{has the candidate been declared yet?} 
var 

1: integer; {loop counter} 
continue: boolean; 
where: nonneg; 
begin 

firstdcl :- true; 
where :■ f ind(candidate); 
if where > then begin 
firstdcl :» false; 
write( linecount: 3, ' — '); 
case SymbolTable [where] .kind of 

nonterminal: write( 'nonterminal '); 
literal: wrlte( 'literal '); 
group: write( 'group '); 
end; 
write('"'); 
i := 1; 

continue := true; 
while continue do begin 
if i = StringSize then 

continue :=■ false 
else if candidate[i] ■ ' ' then 

continue :* false 
else 

write(candldate[i] ); 
i :- i+1; 
end; {while} 
writeln( '" already declared. Second del ignored.'); 
ErrorFree := false; {fatal error} 
end; {if} 
end; {firstdcl} 



(* ASCII *) 



temp[3] :* 'y' 



(* UNIX *) 
(* UNIX *) 
(* UNIX *) 



begin {declarations} 

CardSymbol := 0; {no symbols declared yet} 

spacers := [' ', chr(9)]; {blank and tab} 

axiom := 0; {initially axiom is null} 

temp := AllBlanks; 

temp[l] :=? EndOfSource; {insert end of candidate symbol} 

insert (temp, group); 

{insert "any"} 
temp[l] :» 'a'; temp[2] :<■ 'n'; 
insert (temp, group); 
rewrite(VarFile, 'LLvar.i'); 
rewrite(TypeFile, 'LLtype.i'); 
rewrite(FileFile, 'LLfile.i'); 
readchar; 

skipspace; {find first non-spacer in del section} 
if eh <> '%' then begin 
ErrorFree :<= false; 
writeln(linecount: 3, ' — should begin del with "%".', 

' Skipping until "%" is found'); 
while eh <> '%' do readchar; 
end; {if ch} 
PrintSelect := false; {presume no selection set printout} 
repeat {process one declaration at a time until end of dels} 
readchar; {read selector} 
selector :» ch; 

if selector <> '%' then begin {not end of del section} 
if selector in ['A'..'Z'] then {change u.c. to I.e.} 

selector := chr(ord(selector)+32); (* ASCII *) 
if selector * 's' then begin {print selection sets} 
PrintSelect := true; 

rewrite(LLselect); {prepare to write formatted grammar} 
repeat 

readchar 
until ch - '%'; 
end 
else if selector in ['a', 'g', '1', 'n'] then begin 
{not for llvar.i, llconst.i or lltype.i} 
readchar; {skip past selector} 
skipspace; 
repeat 

fillld(next, spacers); 

if firstdcl(next) then 

case selector of 

'n': begin 

insert(next, nonterminal); 

SymbolTable [find(next) ] .nullable :=• not sure; 

end; 



if axiom « then begin {del axiom for first time} 
insert (next, nonterminal); 
SymbolTable[f ind(next)] .nullable := notsure; 
axiom := find (next); 
end 
else {axiom being redeclared} 
writeln( linecount :3, 

' — axiom declared for second ' , 
'time. Second del ignored.' ); 
: insert(next, literal); 
insert(next, group); 
{case} 



'1 



g : 
end; 
skipspace 
until ch = '%' 
end 
else if selector in ['f, 'v', 't', 'c'] then begin 

{It is a del for inclusion in LLvar, LLtype, LLfile 
or LLconst} 
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readchar; {skip past selector} 
repeat 

case selector of 

'c': write(ConstFile, ch); 
't': write(TypeFile, ch); 
'v': write(VarFile, ch); 
'£': write(FileFile, ch); 
end; {case} 
if eolninput then 
case selector of 

'c': writeln(ConstFile); 
't': writeln(TypeFile); 
'v': writeln(VarFile); 
'f: writeln(FileFile); 
end; {case} 
readchar; 
until ch - '%'; 
end 
else begin {bad selector} 
ErrorFree :» false; 
writeln( linecount: 3 , ' — bad selector "', selector, 

'". Skipping to next "%"'); 
while ch <> '%' do readchar; 
end; 
end 
until selector - '%'; 
readchar; {skip past '%'} 
if axiom ■ then begin 
ErrorFree :« false; 

writeln('You forgot to declare an axiom for your grammar.'); 
end; 
end; {declarations} 

procedure DoProductions; 

{Procedure assumes that ch is first char after IX. It reads 
up through next %%. ch will be second %} 

procedure DoLef tHandSide; {get lhs of production} 
var 

where: nonneg; 

temp: strings; {string value of lhs} 
begin with production[CardProd] do begin 
skipspace; {skip initial blanks} 
line :=* linecount; 

lhs := 0; {always assign lhs a value, even if it is not legal} 
if ch <> '-' then begin 

fillid(temp, spacer s+[ '»']); 
where :=• OrderedFind(temp); 
if where > then begin 

if SymbolTable [where] .kind <> nonterminal then begin 
ErrorFree :» false; 

writeln(printable(temp) , ' should be a nonterminal') 
end 
else if SymbolTable [where] .ProdStart - then 
{first alternative for lhs} 
SymbolTable [where] .ProdStart :» CardProd 
else begin 

ErrorFree :« false; 

writeln(printable(temp), ' should not have second', 

' set of productions.'); 
end; 
lhs := where 
end 
else begin 

ErrorFree :* false; 

writeln(printable(temp) , ' is undeclared.'); 
end; 
skipspace; 
end {if ch} 
else if CardProd > 1 then {not the first production} 
{use lhs of previous production} 
lhs := production[CardProd-l] .lhs 
else begin 

ErrorFree :» false; 

writeln(linecount:3, ' — First production should ', 

'have explicit right-hand side.'); 
end; 
if ch <> '-' then begin {illegal form of production} 
temp := AllBlanks; 
temp[l] := ch; 
ErrorFree := false; 
writeln(printable(temp) , ' found, but "=*" expected after ', 

'left-hand side of production') 
end 
else 

readchar 
skipspace; 
end; {with} 
end; {DoLef tHandSide} 



{skip past »} 



procedure DoRightHandSide; {get the rhs of the production} 
var 

TotalVocab: nonneg; {how many rhs nonterms and terms seen so far?} 

name: strings; 

ProdSynchlndex: Integer; 

ProdCaseSelect : integer; 

procedure CopyAction; {copy action, patch, or synch code to LLact} 
{when CopyAction returns ch will equal closing bracket} 



27 



577. 
578. 
579. 
580. 
581. 
582. 
583. 
584. 
585. 
586. 
587. 
588. 
589. 
590. 
591. 
592. 
593. 
594. 
595. 
596. 
597. 
598. 
599. 
600. 
601. 
602. 
603. 
604. 

605. 
606. 
607. 
608. 
609. 
610. 
611. 
612. 
613. 
614. 
615. 
616. 
617. 
618. 
619. 
620. 
621. 
622. 
623. 
624. 
625. 
626. 
627. 
628. 
629. 
630. 
631. 
632. 
633. 
634. 
635. 
636. 
637. 
638. 
639. 
640. 
641. 
642. 
643. 
644. 
645. 
646. 
647. 
648. 
649. 
650. 
651. 
652. 
653. 
654. 
655. 
656. 
657. 
658. 
659. 
660. 
661. 
662. 
663. 
664. 
665. 
666. 
667. 
668. 
669. 
670. 
671. 
672. 
673. 
674. 
675. 
676. 
677. 



i: integer; 
done : boolean; 

posit: integer; {integer value of n in $n} 
begin with product ion [CardProd] do begin 
nextact :■ nextact+1; 

RhsArray[ThisRhs] .CaseSelect :- nextact; 
writeln(ActFile, ' ', nextact, ': begin'); 
while ch <> '}' do {copy routine} 
if ch - '$' then begin 

if eolninput then writeln(ActFile); 

readchar; 

if ch in .['O'..'9'l then begin {$n form} 

posit :- 0; {determine value of integer} 
while ch in ['0'..'9'] do begin 

posit :- 10*posit + ord(ch)-ord( '0' ); 
if eolninput then writeln(ActFile); 
readchar; 
end; {while} 
if posit > then {number actually follows $} 
{replace string in action routine} 
if posit > TotalVocab+1 then begin {illegal $n} 
writeln(linecount:3, ' — ', 

'$', posit :2, ' refers to symbol not to ' , 
'its immediate right.'); 
ErrorFree :■ false 
end 
else if posit » TotalVocab+1 then {refer to next vocab 
symbol} 

write(ActFile, 'LLStack[LLSentPtr+l] .attribute') 
else begin {walk back to find right vocab symbol} 
done :« false; 

i :■ 0; {how far back we have walked} 
while not done do begin 

{walk back one node over for each symbol 
following the one we want.} 
i :- i+1; 
if RhsArray[ThisRhs-i].kind in 

[nonterminal, literal, group] then 
if RhsArray[ThisRhs-i].WhichVocabSymbol - posit then 

done :- true; 
end; {while} 
write(ActFile, 'LLStack[LLSentPtr-' ,i: 2, '] .attribute'); 
end {else begin} 
else {assign to attribute of lhs} 
writeln(ActFile,'LLStack[LLStack[LLSentPtr], parent J. attribute') 

end {if ch in ['0'..'9']} 
else begin {just write $ and next char} 
write(ActFile, '$'); 
write(ActFile, ch); 
writeln(linecount:3, ' — ', 

'warning — $ embedded in { ... } routine'); 
if eolninput then wrlteln(ActFile); 
if ch - '{' then 

writeln(linecount:3, ' — ', 

'warning — { embedded in { ... } routine'); 
readchar; 
end; {else} 
end {if ch} 
else begin {not a special character — just copy} 
write(ActFile, ch); 
if eolninput then writeln(ActFile); 
if ch - '{' then 

writeln(linecount:3, ' — ', 

'warning — { embedded in { ... } routine'); 
readchar; 
end; {else} 
if eolninput then writeln(ActFile); 
writeln(ActFile); 

writeln(ActFile, ' end; {'* nextact, ' }'); 
end; {with production} 
end; {CopyAction} 



procedure DoSynchronization; 
label 10; 



{process synchronization information} 



name: strings; {token where synch takes place} 
posit: no.nneg; {position in production to recover to} 
begin with production[CardProd] do begin 
readchar; {skip past s} 
if TotalVocab >■ 1 then 

{synch info does not increase CardRhs so CardRhs 
still has the value it had before synch info 
was encountered} 
if RhsArray [ThisRhs] .kind in [nonterminal, group, literal] then 

RhsArray [ThisRhs] .Synchlndex :■ CardSynch+1 
else begin 

ErrorFree :* false; 

writeln(linecount :3, ' — Synchronization info ', 

'must follow a vocabulary symbol.') 
end 
else {synch precedes all vocab symbols} 

ProdSynchlndex :» CardSynch+1 ; 
repeat 

skipspace; 

fillid(name, spacers); 

CardSynch :- CardSynch+1; {SynchData will be stored here} 
SynchData[CardSynch] .Tablelndex :=■ OrderedFind(name); 
if SynchData[CardSynch] .Tablelndex - then begin {undeclared} 
writeln(printable(name) , ' is undeclared.'); 
ErrorFree :=■ false: 
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found but "■" expected 



ch; 



end; 
skipspace; 

if ch <> '»' then begin 
name :» AllBlanks; 
name[l] :■ ch; 
ErrorFree :» false; 
writeln(printable(name) , 
after token name.'); 
while ch <> '}' do readchar; 
goto 10; 
end 
else readchar; {skip past -} 
if ch <> '>' then begin 

name :» AllBlanks; name[l] : 
ErrorFree :» false; 

writeln(printable(name), ' found but ">" expected after "■'"); 
while ch <> '}' do readchar; 
goto 10; 
end 
else readchar; 
skipspace; 

posit :■ 0; {determine value of number} 
while ch in ['0'..'9'] do begin 

posit :« 10*posit + ord(ch) - ord('O'); 
readchar; 
end; 
if posit > then begin 

{posit includes only nonterms and terms — 
TotalVocab has the current number seen} 
if (posit < TotalVocab) then 
begin {illegal to back up} 
ErrorFree := false; 

writeln(linecount:3, ' — synchronization ', 
'may not resume ' , 

'to the left of symbol where error occurs'); 
end; {if posit <} 

posit 



{skip past rest of rhs} 
:» maxint; 



found but 



or integer expected'); 



SynchData [CardSynch] .sent 
end {if posit >} 
else if ch ■ '*' then begin 
SynchData [CardSynch] .sent 
readchar; 
end 
else begin 

ErrorFree := false; 
writeln(printable(name) , 
while ch <> '}' do readchar; 
goto 10; 
end; 
skipspace; 

if ch ■ ',' then readchar {comma separates clauses} 
else if ch = ';' then begin {"clean up" code follows} 
readchar; {skip past semicolon} 
CopyAction; {copy code into LLact} 
if TotalVocab » then {synch code begins rhs} 

ProdCaseSelect := nextact; 
end 
else if ch <> '}' then begin 
ErrorFree := false; 

wrlteln(printable(name) , 'found but comma expected 
after clause.'); 
while ch <> '}' do readchar; 
goto 10; 
end 
until ch » '}'; 

10: readchar; {skip past closing brace} 
end; {with production} 

CardSynch :» CardSynch+1; {add closing synch data} 
SynchData [CardSynch] .Tablelndex :» 0; 
SynchData [CardSynch] .sent :- 0; 
end; {DoSynchronization} 



procedure DoSpecialCode; {process an action, patch, or synch routine} 
begin 

readchar; {skip past open bracket} 
if ch - 's' then 

DoSynchronization 
else begin {patch or action} 
with production [CardProd] do 

if ThisRhs » RhsSize then begin 

wrlteln(linecount:3, ' — more right-hand side', 

elements in productions than limit — ', RhsSize: 4); 
writelnC Recompile "generate. p" after increasing RhsSize'); 
goto 1000; 
end 
else begin 

CardRhs := CardRhs+1; 
ThisRhs := ThisRhs+1; 
with RhsAr ray [ThisRhs] do 

if ch = 'p' then begin {patch for synctactic error} 
kind := patch; 

readchar; {skip past p} 
end {if ch} 
else if ch = 'a' then begin {normal action code} 
kind := action; 
readchar; 
end {else if ch} 
else begin 

writeln(linecount:3, ' — illegal specifier "' , 

ch, '" in {..} code. Assume it is action code.'); 
kind :~ action; 
end; {with} 
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CopyAction; 

readchar; {skip past closing brace} 
end; {else} 
end; {else} 
end; {DoSpecialCode} 



procedure DoSelectionSet; {additional selection set info is processed} 
{Zuse automatically computes selection set for 
each production. However, user can add other 
elements for error processing such as "any", or 
he can tell Zuse how to resolve selection set 
conflicts.} 



{selection set element} 
{location of name in SymbolTable} 



name: strings; 
where: nonneg; 
begin 

{cursor points to '%' which signals beginning of selection set info} 
readchar; {skip past '%'} 
skipspace; 

while ch <> ';' do with production [CardProd] do begin 
fillid(name, spacers+[ ' ; ' ] ); 
where :» OrderedFind(name); 
if where > then {element has been declared} 

if SymbolTable [where] .kind in [literal, group] then 
{element is a terminal} 
resolve :- resolve + [where] 

{add element to resolve which ensures this element 
will end up in selection set of this production and 
not in selection set of alternative productions} 
else begin {element is not legal selection set member} 
ErrorFree := false; 

writeln(printable(name) , ' should be a terminal.') 
end 
else begin {element has not been declared} 
ErrorFree :■ false; 

writeln(printable(name), ' is undeclared.'); 
end; 
skipspace; 
end; {with} 
end; {DoSelectionSet} 



begin with production[CardProd] do begin {DoRightHandSide} 

resolve := []; {no resolvants until found on rhs of production} 
CardSel := 0; {selection set elements not computed yet} 
TotalVocab :* 0; {no nonterms or terms seen yet} 

{haven't seen synch code applicable to entire rhs yet.} 
ProdSynchlndex := 0; 
ProdCaseSelect := 0; 
rhs := ThisRhs+1; {begin storing rhs elements after last 

element of previous production} 
CardRhs :=,- 0; {no rhs elements yet} 

while ch <> ';' do begin {haven't reached end of rhs yet} 
if ch = '{' then {action, patch, or synch routine} 

DoSpecialCode 
else if ch = '%' then {selection set info} 

DoSelectionSet 
else if ThisRhs < RhsSize then begin {normal symbol} 
CardRhs := CardRhs+1; {another rhs element} 
ThisRhs := ThisRhs+1; 

TotalVocab := TotalVocab+1 ; {another term or nonterm} 
with RhsArray[ ThisRhs] do begin 
WhichVocabSymbol := TotalVocab; 
fillld(name, spacers+[ ' ; ' ] ) ; 

{presume no synch info until found} 
Synchlndex := ProdSynchlndex; 

{presume no synch clean up code either} 
CaseSelect: = ProdCaseSelect; 
Tablelndex := OrderedFind(name); 
if Tablelndex > then 

kind := SymbolTable [Tablelndex] .kind 
else begin 

ErrorFree := false; 

writeln(printable(name) , ' is undeclared.'); 

kind := nonterminal; {treat as a nonterminal since this 

is most general vocabulary class.} 
end 
end; {with} 
end {else} 
else if ThisRhs = RhsSize then begin {prods too long} 
writeln(linecount:3, ' — number of right-hand side', 

elements in productions longer than limit — ', RhsSize:4); 



Recompile "generate. p" after increasing RhsSize'); 



{skip to next rhs element} 



writeln( ' 
goto 1000 
end; 
skipspace; 
end; {while} 
readchar; {skip past ';'} 
end; {with} 
end; {DoRightHandSide} 



begin {DoProductions} 

nextact := 0; {no actions yet} 
CardSynch := 0; {no synch data yet} 
CardProd := 0; {no productions yet} 
ThisRhs := 0; {no rhs elements yet} 
writeln('All declarations processed — 
skipspace; 

while (ch <> '%') or (NextChar <> '%') do begin 
CardProd := CardProd+1 ; 



CardSymbol:3, ' symbols.'); 
{another production} 



881. 
882. 
883. 
884. 
885. 
886. 
887. 
888. 
889. 
890. 
891. 
892. 
893. 
894. 
895. 
896. 
897. 
898. 
899. 
900. 
901. 
902. 
903. 
904. 
905. 
906. 
907. 
908. 
909. 
910. 
911. 
912. 
913. 
914. 
915. 
916. 
917. 
918. 
919. 
920. 
921. 
922. 
923. 
924. 
925. 
926. 
927. 
928. 
929. 
930. 
931. 
932. 
933. 
934. 
935. 
936. 
937. 
938. 
939. 
940. 
941. 
942. 
943. 
944. 
945. 
946. 
947. 
948. 
949. 
950. 
951. 
952. 
953. 
954. 
955. 
956. 
957. 
958. 
959. 
960. 
961. 
962. 
963. 
964. 
965. 
966. 
967. 
968. 
969. 
970. 
971. 
972. 
973. 
974. 
975. 
976. 
977. 
978. 
979. 
980. 
981. 



if CardProd > ProdSize then begin 

writeln(linecount :3, ' — too many productions.'); 

writelnC Recompile "generate. p" with ProdSize increased.' 

goto 1000; 

end; 
production[CardProd] .nullable := notsure; 
DoLeftHandSide; 
DoRightHandSide; 
skipspace; 
end; {while} 
{DoProductions} 



begin {DoGrammar} 

LineLength :- 0; {initially line is empty} 

LineMarker := maxint; {force the reading of the first input line} 

linecount := 0; {no lines read yet} 

rewrite(ActFile, 'LLact.l'); (* UNIX *) 

writeln(ActFile, ' procedure LLTakeAction(CaseIndex: integer);'); 

{set up for case stmt} 
writelnC ActFile, ' begin'); 
writelnC ActFile, ' case Caselndex of); 
writelnC ActFile, ' 0:;'); 

declarations; 

SortTable; {sort the symbol table} 
DoProductions; 
for i :- 1 to CardSymbol do with SymbolTable [ i ] do 

if CProdStart - 0) and (kind - nonterminal) then begin 

writelnC 'Nonterminal ', value, ' does not appear on the'); 

writelnC left-hand-side of any production.'); 

ErrorFree :=» false 

end; 



writelnCActFile); 
writelnC ActFile, ' 
writelnCActFile, ' 
end; {DoGrammar} 



end; {case}'); 
end; {LLTakeAct} ') ; 



procedure ComputeSelectionSets; {compute selection set of each production} 

{store in select field of production} 
type 

matrix « packed array [L.TableSize] of intset; 
var 

timer: real; {keep track of time used for computation} 

AllTerms: intset; {set of all literals and groups — the terminals} 

i,j: integer; {loop counter} 

BDW: matrix; {holds "begins directly with" relation originally — 

eventually becomes "begins with" relation} 
IDEO: matrix; {holds "is direct end of" relation originally — 

eventually becomes "is end of" relation} 
IFDB: matrix; {holds "is followed directly by" relation 
which eventually becomes "is followed by" 
and then "extended is followed by"} 



procedure MatrixMultC var 1, r, result: matrix); 

{multiply matrices 1 and r yielding result} 
var 

i,j,k: integer; 
temp: intset; 
begin 

for i :« 1 to CardSymbol do {initially result is empty} 

result[i] := []; 
for j := 1 to CardSymbol do begin {j is the column index} 
temp :- []; 
for k := 1 to CardSymbol do {build j-th column of matrix r} 

if j in r[k] then temp := temp + [k] ; 
for i := 1 to CardSymbol do {i is the row index} 
if (l[i]*temp) <> [] then 

{i-th row and j-th column yield non-empty product} 
result[i] := result[i] + [j]; 
end; {for j} 
end; {MatrixMult} 



procedure FindNullable; 
label 10; 



{compute nullable nonterminals and productions} 



change: boolean; 
i,j: integer; 



{loop counters} 



begin 

change :» false; 

for i := 1 to CardProd do with production!!] do 
if CardRhs - then begin 

SymbolTable [lhs] .nullable :» null; 
nullable :=* null; 
change := true 
end; {if CardRhs - 0} 
while change do begin {add to list of nullables} 

change := false; {must make a change each iteration} 
for i := 1 to CardProd do begin with production[i] do 
if nullable = notsure then begin 

for j := rhs to CardRhs+rhs-1 do with RhsArraytjI do 
case kind of 

group, literal: begin 
nullable := never; 
goto 10; 

end; {group, literal} 
action, patch: ; 
nonterminal: 

case SymbolTable [Tablelndex] .nullable of 
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never: begin 

nullable := never; 
goto 10; 
end; {never} 
notsure: goto 10; 
null: ; 

end; {case SymbolTable} 
end; {case kind} 
nullable :■ null; 

SymbolTable [lhs] .nullable :» null; 
change :» true; 
end; {if nullable} 
10: ; {early exit for loop} 
end; {for i } 
end; {while change} 
end; {FindNullable} 



function NotNullable( index: nonneg) : boolean; 

{is, SymbolTable [index] .value nullable?} 
begin with SymbolTable [index] do 
case kind of 

nonterminal: if nullable » null then NotNullable := false 

else NotNullable := true; 
literal, group: NotNullable := true; 
end; {case kind} 
end; {NotNullable} 



procedure Ref lexTrans(var RT: matrix); 

{compute reflexive transitive closure of RT} 
var 

i,j,k: integer; 
done: boolean; 
temp: intset; 
begin 

for i := 1 to CardSymbol do {make relation reflexive} 

RT[i] := RT[i] + [i]; 
repeat {compute closure} 

done :=« true; {assume no change until proven otherwise} 
for j := 1 to CardSymbol do begin {j is the column index} 
temp :- []; 
for k := 1 to CardSymbol do {build j-th column of RT} 

if j in RT[k] then temp := temp + [k] ; 
for i := 1 to CardSymbol do begin {i is the row index} 
if not (j in RT[i]) then 

if (RT[i]*temp) <> [] then begin 

{i-th row and j-th column yield non-empty product} 
RT[i] := ,RT[i] + [j]; 
done :=» false; 
end; 
end; {for 1} 
end; {for j} 
until done; 
end; {Ref lexTrans} 



procedure ExtendedIsFollowedBy( var EIFB, IEO: matrix); 

{add EndOfSource info to "is followed by" relation} 
{presume EIFB is originally "is followed by"} 
var 

i: integer; 

where: integer; {location of EndOfSource in SymbolTable} 
temp: strings; {EndOfSource padded with blanks} 
begin 

temp :■ AllBlanks; 
temp[l] :- EndOfSource; 
where :» OrderedFind(temp); 
for i :- 1 to CardSymbol do 

{if symbol is at the end of the axiom then EndOfSource 
is at the end of symbol} 
if axiom in IE0[i] then 

EIFB[i] :- EIFB[i] + [where]; 
end; {ExtendedlsFollowedBy} 



procedure IsFollowedBy( var IFB, IEO, BW: matrix); 

{x is followed by y if xy is a substring of some sentential form} 
var 



temp: matrix; 
begin {IsEndOf x IsFollowedBy x 

MatrixMult(IE0, IFB, temp); 

MatrixMult(temp, BW, IFB); 
end; {IsFollowedBy} 



BeginsWith} 



procedure IsEnd0f( var IEO: matrix); 

{ B is end of C if there is a derivation C -> wB 
In any number of steps} 
begin 

{presume IEO Is originally "is direct end of" relation} 
ReflexTrans(IEO); 
end; {IsEndOf} 



procedure IsDirectEndOf ( var IDEO: matrix); 

{ B is the direct end of C if there is a production 
C -> wBz where z is nullable} 
label 10; 
var 

i,j: integer; 
begin 
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for i :■ 1 to CardSymbol do {assume no direct end of SymbolTable [1]} 

IDE0[i] :- []; 
for i :« 1 to CardProd do with production[i] do begin 

for j :» rhs+CardRhs-1 downto rhs do with RhsArraytj] do begin 
{search from right to left on rhs of production} 
if RhsArray[ j] .kind in [nonterminal, group, literal] then begin 
IDEO [ RhsAr ray [ j ]. Table Index ] : - 

IDE0[RhsArray[j]. Tablelndex] + [lhs]; 

{no point searching past first non-nullable symbol} 
if NotNullable(RhsArray[j].TableIndex) then goto 10; 
end; {if RhsArray} 
end; {for j} 
10: 

end; {for i} 
end; {IsDirectEndOf} 



procedure IsFollowedDirectlyBy( var IFDB: matrix); 

{B is followed directly by C if there is a production 
D -> wBzCx where z is nullable} 
label 10; 
var 

i,j,k: integer; 
begin 

for i :■ 1 to CardSymbol do {presume symbol is not followed by anything} 
IFDB[I] :- []; 

for i :■ 1 to CardProd do with production! i] do 

for j :- rhs to rhs+CardRhs-1 do with RhsArray [j] do begin 
if kind in [nonterminal, group, literal] then 
for k :■ j+1 to rhs+CardRho-1 do begin 

if RhsArray [k] .kind in [nonterminal, literal, group] then 
begin 

IFDB [Table Index] :- IFDB [Table Index] + 
[RhsArray[k] .Tablelndex] ; 

{don't search past first non-nullable symbol} 
if NotNullable ( RhsArray [k] . Tablelndex) then goto 10; 
end; {if RhsArray} 
end; {for k} 
10: 

end; {for j} 
end; {IsFollowedDirectlyBy} 



procedure BeginsDirectlyWith( var BDW: matrix ); 

{C begins directly with B if there is a production 
C — > wBz where w is nullable} 
label 10; 
var 

i,j: integer; 
begin 

for 1 :■ 1 to CardProd do with production! i] do begin 
for j :- rhs to rhs+CardRhs-1 do with RhsArray [j] do 
if kind in [nonterminal, group, literal] then begin 
BDW[lhs] :- BDW[lhs] + [Tablelndex]; 
if NotNullable( Tablelndex) then goto 10; 
end; {if kind} 
10: 

end; {for i} 
end; {BeginsDirectlyWith} 



procedure BeginsWith( var BW: matrix); 

{C begins with B if there is a derivation C ■■> Bw 
in any number of steps} 
begin 

Ref lexTrans (BW); 
end; {BeginsWith} 



procedure FlrstSymbol( var FS: matrix); 

{terminal b is a FirstSymbol of B if there is a derivation 
C «■> bw in any number of steps} 
begin 

for i :» 1 to CardSymbol do 

if SymbolTable [i] .kind » nonterminal then 

FS[i] :- FS[ij* AllTerms 
else 

FS[i] :- [i]; 
end; {FirstSymbol} 



procedure FirstProd( var FS: matrix); 

{terminal b Is in FirstProd of production C — > w 

if C »■> w »■> bz for sentential form bz in any 
number of steps} 

{store computed answers in "select" field of production 
since this is part of the selection set info} 
label 10; 
var 

i,j: integer; 
begin 

for i :» 1 to CardProd do with production!!] do begin 
{presume selection set is empty} 
select :- []; 

{add Fir8tSymbols of rhs elements up thru 
first non-nullable element} 
for j :« rhs to rhs+CardRhs-1 do with RhsArraytj] do begin 
if kind in [nonterminal, literal, group] then begin 
select :- select + FS [ Tablelndex] ; 
if NotNullable(Tablelndex) then goto 10; 
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1185. 
1186. 
1187. 
1188. 
1189. 
1190. 
1191. 
1192. 

1193. 
1194. 
1195. 
1196. 
1197. 
1198. 
1199. 
1200. 
1201. 
1202. 
1203. 
1204. 
1205. 
1206. 
1207. 
1208. 
1209. 
1210. 
1211. 
1212. 
1213. 
1214. 
1215. 
1216. 
1217. 
1218. 
1219. 
1220. 
1221. 
1222. 
1223. 
1224. 
1225. 
1226. 
1227. 
1228. 
1229. 
1230. 
1231. 
1232. 

1233. 
1234. 
1235. 
1236. 
1237. 
1238. 
1239. 
1240. 
1241. 
1242. 
1243. 
1244. 
1245. 
1246. 
1247. 
1248. 
1249. 
1250, 
1251. 
1252. 
1253. 
1254. 
1255. 
1256. 
1257. 
1258. 
1259. 
1260. 
1261. 
1262. 
1263. 
1264. 
1265. 
1266. 
1267. 
1268. 
1269. 
1270. 
1271. 
1272. 
1273. 
1274. 
1275. 
1276. 
1277. 
1278. 
1279. 
1280. 
1281. 
1282. 
1283. 
1284. 



end; {if kind} 
end; {for j} 
10: 

end; {for i} 
end; {FirstProd} 



procedure HandleResolvants; {give priority to resolvants in 
selection sets} 
label 10; 
var 

i,j: integer; 
begin 

for i :■ 1 to CardProd do with production[i] do 
if resolve <> [] then begin 

for j :- SymbolTable [ lhs ] .ProdStart to CardProd do 
if production! j] .lhs <> lhs then 

goto 10 
else 

production! j] .select :» production! j] .select-resolve; 
10: 

select :- select + resolve; 
end; {if resolve} 
end; {HandleResolvants} 



procedure HandleConflicts; {report conflicts among alternative 

productions and resolve conflicts as indicated by supplemental 
selection set info stored in resolve} 
label 10; 
var 

any: boolean; 
i,j,k: integer; 
intersect: intset; 
begin 

any :■ false; 

for i :« 1 to CardProd do with product ion[i] do begin 
for j :» i+1 to CardProd do 

if production! j] .lhs - lhs then begin 

intersect :» select*production[ j] .select; 
production! j] .select :» production! j] .select - intersect; 
if intersect <> [] then begin {conflict!} 
if not any then begin 

if PrintSelect then begin 

writeln(LL8elect, "There are selection set conflicts ' 

' as indicated:'); 
writeln(LLselect); 
end; 
writeln( 'There are selection set conflicts as 
indicated:'); 
wrlteln; 
any :=* true 
end; 
for k := 1 to CardSymbol do 

if k in intersect then begin 
if PrintSelect then 

writeln(LLselect, SymbolTable !k] .value, ' in ' , 
'prods at lines ', 
production [i] .line : 3, 
' and ', production! j] .line: 3, ' with', 
' left-hand side ', SymbolTable [lhs] .value); 
writeln( SymbolTable [k] .value, ' in ' , 
'prods at lines ' , 
production! i] .line : 3, 
' and ', production! j] .line: 3, ' with', 
' left-hand side ', SymbolTable! lhs] .value); 
end; 
end; 
end {if production} 
else goto 10; {no more alternatives} 
10: 

end; {for i} 
if PrintSelect then begin 

writeln(LLselect); writeln(LLselect); end; 
end; {HandleConflicts} 

begin {ComputeSelectionSets} 

timer :* clock; {keep track of how much time to compute selection sets} 
(* UNIX *) 
writeln( 'Starting to compute selection sets — ', CardProd:3, 

' productions.'); 
FindNullable; {determine which symbols and prods are nullable 
— store answers in SymbolTable and productions 
respectively} 

{compute set of all terminals} 
AllTerms :- []; {initially empty} 
for i :- 1 to CardSymbol do 

if SymbolTable [i] .kind in [literal, group] then 
AllTerms :- AllTerms + [i]; 

for i :- 1 to CardSymbol do {initially, BDW is empty} 
BDW[i] :- []; 

BeginsDirectlyWith( BDW ); 
BeginsWith( BDW ); 
FirstSymboK BDW ); 
FirstProd( BDW ); 

{at this point selection set for each production 
already includes first of rhs as computed in 
FirstProd — just add Follow info if needed } 



1285. 
1286. 
1287. 
1288. 
1289. 
1290. 
1291. 

1292. 
1293. 
1294. 
1295. 
1296. 
1297. 
1298. 
1299. 
1300. 
1301. 
1302. 
1303. 
1304. 
1305. 
1306. 
1307. 
1308. 
1309. 
1310. 
1311. 
1312. 
1313. 
1314. 
1315. 
1316. 
1317. 
1318. 
1319. 
1320. 
1321. 
1322. 
1323. 
1324. 
1325. 
1326. 
1327. 
, 1328. 
1329. 
1330. 
1331. 
1332. 
1333. 
1334. 
1335. 
1336. 
1337. 
1338. 
1339. 
1340. 
1341. 
1342. 
1343. 
1344. 
1345. 
1346. 
1347. 
1348. 
1349. 
1350. 
1351. 
1352. 
1353. 
1354. 
1355. 
1356. 
1357. 
1358. 
1359. 
1360. 
1361. 
1362. 
1363. 
1364. 
1365. 

1366. 
1367. 
1368. 
1369. 
1370. 
1371. 
1372. 
1373. 
1374. 
1375. 
1376. 
1377. 
1378. 
1379. 
1380. 
1381. 

1382. 
1383. 



IsDirectEndOf(IDEO); {computes "is direct end of" relation} 
IsEndOf(IDEO); {transforms "is direct end of" into "is end of"} 
IsFollowedDirectlyByC IFDB) ; 
IsFollowedBy(IFDB, IDEO, BDW); {transforms "is followed directly 

by" into "is followed by"} 
ExtendedIsFollowedBy( IFDB, IDEO); {adds info for EndOf Source 
marker to 

"is followed by"} 

{can now add Follow info to select field} 
for i :■ 1 to CardProd do with production!!] do 
if nullable - null then {add terminal symbols} 
select :- select + IFDB[lhs]; 
HandleResolvants ; 
HandleConflicts; 

for i :■ 1 to CardProd do with production! i] do 
for j :■ 1 to CardSymbol do 
if j in select then 

CardSel :- CardSel+1; 
writeln( 'Seconds CPU time to compute selection sets — ', 

(clock-timer)/1000.0 :5:2 ); {time is in milliseconds} 
(* UNIX *) 
end; {ComputeSelectionSets} 



procedure SaveGrammar; 



{save entire grammar on disk in LLgram. 
Print grammar with selection sets on LLselect 
if requested.} 



NumValue: integer; {number of selection set or vocabulary elements 

on current line of LLselect.} 
i,j: nonneg; {loop counter} 
Number Of Terminals : nonneg; 

WhichTerminal : array! 1 . .TableSize] of integer; {which numbered 
terminal SymbolTable! i] is} 
begin 

rewrite(LLgram) ; 

{write Symbol Table} 
NumberOf Terminals :- 0; 

for i :« 1 to CardSymbol do with SymbolTable [i] do 
if kind in [literal, group] then begin 
{write symbol and kind} 
NumberOfTerminals :=* NumberOfTerminals+1; 
LLgram*. table :=■ value; 
put(LLgram); 
if kind ■ group then 

LLgram*. table [1] :- 'g' 
else 

LLgram*.table[l] :- '1'; 
put (LLgram); 

WhichTerminal [i] :- NumberOfTerminals; 
end; {if kind} 
writeln(ConstFile, ' LLTableSIze - ', NumberOfTerminals :4, ';'); 

{now the productions} 
if PrintSelect then begin {print heading of selection set report.} 

writeln(LLselect, 'Grammar productions with selection sets added:'); 
writeln(LLselect) ; 

writeln(LL8elect, 'Prod # Line # Production'); 
writeln(LLselect); 
end; 
LLgram*. grammar :- SymbolTable [axiom] .ProdStart; put (LLgram); 
for j :■ 1 to CardProd do 

with production [ j] do begin 
if PrintSelect then begin 
writeln(LLselect); 
write(LLselect, j:3, line: 9, ' ', 

PrintString( SymbolTable [lhs] .value) , ' - '); 
end; {if PrintSelect} 
LLgram*. grammar :- SymbolTable [lhs] .ProdStart; put(LLgram); 
LLgram*. grammar :» CardRhs; put(LLgram); 

NumValue :» 0; {no vocab symbols on current line of LLselect yet} 
for i :- rhs to rhs+CardRhs-1 do'with RhsArray[i] do begin 
if PrintSelect then begin 

if NumValue - 6 then begin 
writeln(LL8elect) ; 

write(LLselect,' '); 

NumValue :- 
end; {if NumValue} 
NumValue :- NumValue + 1; 
if kind in [nonterminal, literal, group] then 

write(LLselect, PrintString( SymbolTable [Tablelndex] 
.value)) 
else if kind - action then 

write(LL8elect, ' {a..} ') 
else 

NumValue :=» NumValue - 1; {didn't print anything} 
end; 



case kind of 

nonterminal: begin 
LLgram* .grammar 
LLgram* . grammar 
put (LLgram); 
LLgram* . grammar 
LLgram* .grammar 
end; 
group: begin 

LLgram* .grammar 
LLgram* . grammar 
(LLgram); 
LLgram* .grammar 
LLgram' 



ord('n'); put(LLgram); 
SymbolTable [Tablelndex] .ProdStart; 

CaseSelect; put (LLgram); 
Synchlndex; put (LLgram); 



:« ord('g'); put(LLgram); 

:» WhichTerminal [Tablelndex]; put 



:=■ CaseSelect; put (LLgram); 
:- Synchlndex; put (LLgram); 
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1384. end; 

1385. literal: begin 

1386. LLgram*. grammar :» ord('l'); put(LLgram); 

1387. LLgram*. grammar :» WhichTerminal[TableIndex]; put(LLgram); 

1388. LLgram*. grammar :- CaseSelect; put(LLgram); 

1389. LLgram*. grammar :■ Synchlndex; put(LLgram); 

1390. end; 

1391. patch: begin 

1392. LLgram". grammar :- ord('p'); put(LLgram); 

1393. LLgram*. grammar :» CaseSelect; put(LLgram); 

1394. end; 

1395. action: begin 

1396. LLgr am". grammar :- ord('a'); put(U,gram); 

1397. LLgram*. grammar :- CaseSelect; put(LLgram); 

1398. end; 

1399. end; {case} 

1400. end; {if} 
1401. 

1402. {write out selection set info} 

1403. if PrintSelect then begin 

1404. writeln(LLselect); 

1405. write(LLselect, ' l')\ 

1406. end; 

1407. LLgram*. grammar :» CardSel; put(LLgram); 

1408. NumValue :- 0; {how many selection set elements printed on 

1409. current line of LLselect} 

1410. for i :- 1 to CardSymbol do 

1411. if i in select then begin 

1412. LLgram*. grammar :- WhichTerminal[i] ; put(LLgram); 

1413. if PrintSelect then begin 

1414. if NumValue - 6 then begin 

1415. writeln(LLselect); 

1416. write(LLselect, ' '); 

1417. NumValue :» 0; 

1418. end; {if NumValue} 

1419. NumValue :« NumValue + 1; 

1420. write(LLselect, PrintString(SymbolTable[i] .value)); 

1421. end; {if PrintSelect} 

1422. end; {if i} 

1423. if PrintSelect then 

1424. writeln(LLselect, ' ;'); 

1425. end; {with production} 
1426. 

1427. {write how large RhsArray is} 

1428. writeln(ConstFile, ' LLRhsSize - ', ThisRhs:4, ';'); 
1429. 

1430. {write out synchronization info} 

1431. for i :» 1 to CardSynch do begin 

1432. if SynchData[i], Table Index <> then 

1433. LLgram*. grammar :- WhichTerminal[SynchData[l] .Table Index] 

1434. else 

1435. LLgram". grammar :» 0; put(LLgram); 

1436. LLgram*. grammar :- SynchData[i] .sent; put(LLgram); 

1437. end; {for i} 

1438. end; {SaveGrammar} 
1439. 

1440. 

1441. begin {main program} 

1442. ErrorFree :- true; {initially no errors in grammar} 

1443. for i :■ 1 to StringSize do 

1444. AllBlanks[i] :- ' '; 

1445. rewrite(ConstFile, 'LLconst.i' ); (* UNIX *) 

1446. writeln; 

1447. DoGrammar; 

1448. if ErrorFree then begin 

1449. ComputeSelectionSets; 

1450. SaveGrammar; 

1451. end 

1452. else 

1453. writeln( 'Selection sets not computed because of fatal error.'); 

1454. writeln(ConstFile, ' LLProdSize » ', CardProd, ';'); 

1455. writeln(ConstFile, ' LLSynchSlze - ', CardSynch, ';'); 

1456. writeln(ConstFile, ' LLStringLength - ', StringSize, ';'); 

1457. 1000: 

1458. writeln; 

1459. end. 
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1 6032 PROCESSOR GETS 

PASCAL, PL/1, FORTRAN, 

AND C COMPILERS 

Globally optimizing, commercial -grade 
compilers for PL/1, Fortran, Pascal, and C lan- 
guages are now available for National Semi- 
conductor's 16032 microprocessor. The units 
are available both as cross-compilers and as 
native compilers running under Bell Laborato- 
ries' Unix operating system— though they may 
easily be retargeted to other operating systems. 

Translation Systems Inc. claims that tests of 
its Pascal programs by an independent tele- 
communications firm found a code density of 
1.4, compared with 1.7 for National's and 2.2 
for Motorola's. Theoretically, a proficient as- 
sembler programmer would write a code size 
of 1. 

The company is currently offering original- 
equipment manufacturers distribution licenses 
for a one-time fee of $97,500, plus royalties. 
Products in the works include compilers for 
RPG-II, Cobol, Basic, and a full PL/1 
implementation. 

Tom Lindin, Translation Systems Inc., 
530 Atlantic Ave., Boston, MA 02210 
Phone (617) 357-9433 



'DBX'— NEW PRODUCT 

Pascal & Associates of Chapel Hill, NC, an- 
nounces a new product intended for PASCAL 
programmers who wish to develop data man- 
agement applications. DBX stores keyed data- 
strings passed to it from a calling program. It is 
fast, simple, efficient, and inexpensive. It is 
written entirely in PASCAL. It is available — 
on disk — for the Apple II -h /He and IBM PC 
microcomputers, Apple- and IBM-compati- 
bles, and computers with standard 8" SSSD 
disk format. Since DBX includes complete 
source listings, it can be entered and used on 
any computer with a PASCAL compiler. 

DBX stores variable-length keyed strings of 
data in a disk file. It uses a modified ISAM (In- 



dexed Sequential Access Method): It divides its 
keyed entries into "pages," and indexes the 
pages. In each page, the entries themselves are 
kept sorted. Each page consists of an exact 
number of disk blocks. This enables DBX to 
use high-speed fixed-length disk I/O routines. 
Thus, DBX can stores and retrieve entries very 
quickly, while limiting the average number of 
disk accesses to one per operation. 

DBX also maintains memory dynamically; 
it minimizes — at run-time — the memory it 
uses. The number of files that DBX can simul- 
taneously manipulate is limited only by the 
amount available memory. 

DBX is modular; it comes as an "Intrinsic 
Unit" for inclusion in a UCSD p-System li- 
brary. You can write a program to call it, or 
modify the calling program we've included as 
an example, or modify DBX itself. Calling pro- 
grams pass a simple "callblock" containing in- 
put keys, input data, and operations; DBX re- 
turns output keys, output data, the output 
page, and a result code for the success or fail- 
ure of the operation. 

For $49.95, you get OBJECT AND 
SOURCE CODE for three programs: 

• DBX itself; 

• 'MINIBASE,' a simple example program 
that calls DBX to store, retrieve, or delete 
entries; 

• 'DBTEST,' a diagnostic 'testbed' program 
that calls DBX, and displays all current 
input and output information. 

You also get a 50-page manual that describes 
the data structures, procedures, and principal 
algorithms for all three programs, and gives 
many suggestions for modifying them for dif- 
ferent purposes. 

With no changes at all, MINIBASE is al- 
ready an ideal user -oriented package for bibli- 
ographies, glossaries, inventory catalogs, and 
similar applications. 

DBX is available only from Pascal & Associ- 
ates, 135 East Rosemary Street, Chapel Hill, 
NC 27514. Send $49.95 plus $3.00 for ship- 
ping costs; or call 9 1 9-942- 1 4 1 1 — we take ma- 
jor credit cards. 



PLUMB 

LOUISVILLE, KY — Riverside Data Inc. 
introduces a new publication designed to help 
personal computer users get more work, fun 
and information out of their machines. 

"PLUMB — Probing the World of Personal 
Telecommunications" is a newsletter to help 
computer users explore the many services 
available when the computer is connected with 
a modem and a telephone. 

PLUMB contains information of interest to 
computer users, regardless of their level of ex- 
pertise or the brand of computer they own. 

Unlike a particular software program, tele- 
communications is a common denominator, al- 
lowing owners of all types of machines to com- 
municate, share ideas and "homegrown" soft- 
ware, and obtain a wide range of sophisticated 
services. 

The popularity of commercial timesharing 
services such as The Source and CompuServe 
is evidence of the growing interest in personal 
telecommunications. 

Though most computer owners are aware of 
these services, there are hundreds of private 
and company-sponsored databases and sys- 
tems that deliver a vast array of services free or 
at a minimal cost. PLUMB features these 
other services: 

• Electronic mail 

• Software sales and exchange 

• Dating services and adult bulletin boards 

• Financial and investment information 

• Merchandise sales 

• Online games 

Some "underground" bulleting boards even 
deal with information to help crack protected 
software. PLUMB reports on new systems and 
features added to established systems. And it 
publishes reports designed to help computer 
users get what they want, faster and more effi- 
ciently. 

Riverside Data's intention is to provide the 
home computer user with the kind of usable, 
non-technical information about telecommuni- 
cations available nowhere else. 

Computer magazines are filled with articles 
and advertisements about modems and com- 
munication programs, but very little informa- 
tion about what's available once the user is 
ready to go online. 

One big attraction of telecommunications is 
its ability to serve as a common ground for all 
types of computers. Apple users can trade 
ideas with Atari users. Radio Shack owners 
can talk to IBM people. It's like an enormous 
festival for millions of computer owners. 

PLUMB sells for $20 for the five issues pub- 
lished in 1983. Subscriptions should be mailed 
to: Riverside Data Inc., P.O. Box 300, Harrods 
Creek, KY 40027. 
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SCENIC COMPUTER INTRODUCES 

SPRINTER-2, A TEXT 

PROCESSOR FOR LARGE DOCUMENTS 

SEATTLE, WA - SPRINTER-2, a new 
text processor has been developed by Scenic 
Computer Systems, Inc., specifically to meet 
the demands of producing books, reports, 
manuals and other large documents. 

SPRINTER-2 frees the user from tedious 
and error-prone tasks such as compiling and 
verifying indices, tables of contents, lists of 
figures, and maintaining forward and back- 
ward references. Automatic numbering of 
chapters, sections, and pages reduces prepara- 
tion time. 

SPRINTER-2's built-in text formatting com- 
mands include automatic footnote placement 
and numbering, multicolumn formats, and 
powerful header and footer line capabilities. 

According to Erik Smith, Scenic's President, 
"The real power of SPRINTER-2 lies in its 
Macro Formatting Language. The user can de- 
fine macros (one word instructions) to carry 
out any sequence of the built-in commands 
and other macros." 

The use of macros minimizes commands 
embedded in the text and assures consistency 
throughout a document. An entire document 
can be reliably reformatted in minutes simply 
by changing the macros definitions. 

A text file can be printed without modifica- 
tion on any of the supported printers with any 
type style, since SPRINTER-2 does not rely on 
any printer specific features. 

Since proofing a large document for spelling 
and typing errors is a major task, a spelling 
checker with an expandable 40,000 word dic- 
tionary is available. 

SPRINTER-2 supports all popular daisy- 
wheel printers, including Diablo 630 and 1600 
Series, NEC Spinwriters, Printmaster F-10, 
Starwriter F-10, Transtar 130 and 140, and 
Qume Sprint. Drivers for additional printers, 
phototypesetters and laser printers are under 
development. 

SPRINTER-2 is written in Pascal and is 
available for any computer using SofTech Mi- 
crosystems' p-System. This includes Corona, 
Compaq DEC PDP and LSI 1 1/23, IBM Per- 
sonal Computer, NEC Advanced Personal 
Computer, Sge II and Sage IV, Scenic Model 
One, Texas Instrucments Professional Com- 
puter, and Victor 9000/Sirius 1. 

SPRINTER-2 is priced at $350. The option- 
al spelling checker is $125. Product literature 
or the 140-page users' manual can be obtained 
by contacting Scenic Computer Systems, Inc., 
14852 NE 31st Circle, Redmond, WA 98052; 
(206) 885-5500. 



NEWEST SAGE 
SUPERMICROS BROCHURE 

Sage Computer Technology of Reno, NV, 
has just published a full-color brochure de- 



scribing its new family of high-performance 
microcomputers. 

The line has been expanded from one model 
to four, including the original Sage II in a 
brand new low-profile configuration. 

A mere 3-7/8" from desk top to computer 
top, the low-profile Sage II packs the same 
power its predecessor is famous for — 2 million 
operations per second, on-board RAM expand- 
ability to 1/2 MByte, p-System, RAM-Disk, 
and one or two built-in low-profile floppy 
drives. 

Three Sage IV models offer the same level 
of performance, plus RAM expandability to 1 
MByte. Varying Winchester capacities and 
cabinet sizes distinguish the three. 

The smaller Sage IV provides 10 MBytes of 
built-in Winchester capacity, while the largest 
boasts four built-in Winchesters totaling 200 
MBytes. In each case, one or two 640 KByte 
floppy drives may be specified. 

All four Sage computers typically load a 
20K program from floppy diskette in about a 
second, according to a company spokesman. 
He said the unique Sage architecture, which 
permits the Motorola 68000 processor to han- 
dle data from the drives without skewing and 
interleaving, accounts for the remarkable 
loading speed. 

The literature also includes a great deal of 
information about the standard operating sys- 
tem, the UCSD p-System. CP/M-68K, Modula 
2 and Hyper-Forth operating systems are op- 
tionally available. 

To receive a free copy of the brochure, write 
to Sage Computer Technology, 4905 Energy 
Way, Reno, NV 78502. The phone number is 
(702) 322-6868. 



PROGRAMMING A PERSONAL 
COMPUTER IN EDISON 

The book Programming a Personal Comput- 
er by Per Brinch Hansen has now been pub- 
lished. It describes the Edison System, a port- 
able software system for small, personal com- 
puters, and illustrates how the principles of 
programming languages, compilers, operating 
systems and computer architecture are applied 
in the design of a complete software system. 

The book includes the program text of an 
operating system and a compiler written in the 
programming language Edison and describes 
an instruction set tailored to the language. It 
also includes the text of a system kernel which 
interprets the portable Edison code. 

Last September, a class of USC undergradu- 
ates used the book and the software to build 
working operating systems for IBM Personal 
Computers. They now hve the necessary prac- 
tical background to appreciate the theoretical 
principles of operating systems. 



The book is published by Prentice-Hall, 
Englewood Cliffs, NJ 07632. The Edison Sys- 
tem is currently available for the Compaq 
Portable Computer and the LSI II Computer. 
The software is distributed by Professor Per 
Brinch Hansen, Computer Science Depart- 
ment, University of Southern California, Los 
Angeles, CA 90089. 



CALL FOR PAPERS 

SCS Conference on Simulation in Strongly 
Typed Languages ADA, PASCAL, SIMULA, 
... * This conference will provide a forum for 
presenting new approaches to developing, vali- 
dating, and using simulation models. The fo- 
cus will be on high level implementation lan- 
guages. In particular, we solicit new approach- 
es based on ADA, PASCAL, SIMULA, and 
other strongly typed languages. Accepted 
papers will appear in the conference Proceed- 
ings. Areas of interest include: 

• Simulation in ADA, including discrete 
event, continuous, and combined approaches. 

• Programming environments tailored to 
modeling and simulation, particularly those 
based on ADA, PASCAL, or SIMULA. 

• Interactive model development and analy- 
sis, including interactive graphics tools and 
model specification languages. 

• Novel hardwre and software architectures 
that support efficient model execution. 

• The simulation of distributed computer sys- 
tems and, in particular, software simulation 
and prototyping. 

DEADLINES AND REQUIREMENTS 

Papers should be no longer than 5,000 
words, approximately 20 double-spaced pages 
in length, with author names appearing only 
on the cover paper. All papers will be refereed. 
Extended abstracts will also be considered. 
Submit five copies of the paper by 15 July 
1983 to: 

Dr. Ray Bryant 

IBM T.J. Watson Research Center 

P.O. Box 218 

Yorktown Heights, NY 10598 

(914) 945-3542 
Authors of accepted papers will be notified 
by 1 September 1983. Camera-ready copies 
will be due no later than 1 November 1983. 

CONFERENCE SITE 

The conference will be held in beautiful San 
Diego, CA. This is your opportunity to com- 
bine an outstanding educational experience 
with a vacation from winter. Bring your family! 
*This conference will be held as part of the 
SCS Multiconference, incorporating Modeling 
and Simulation on Microcomputers, Simula- 
tion in Strongly Typed Languages: ADA, 
PASCAL, SIMULA, . . ., and Simulation in 
Health Care Delivery Systems. 
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SCREEN EDITOR 

LETS USERS DEFINE 

FUNCTION KEYS, 

BOOSTS PRODUCTIVITY 

User-definable function keys (macros) are 
available for the first time on a microcomputer 
screen editor that can run on all major hard- 
ware systems, including the IBM Personal 
Computer and the Apple II™, according to 
Volition Systems, developer of the software. 

Called the Advanced System Editor (ASE), 
the software can be adapted to a variety of ter- 
minals and can increase productivity at the key- 
board by at least 25 percent, according to Joel 
J. McCormack, company chairman. 

ASE is now available for all versions of the 
UCSD Pascal™ system. It offers OEM's, soft- 
ware suppliers and end users important ad- 
vances over the original screen-oriented editor, 
which as been a major strength of all UCSD 
Pascal development systems. 

"ASE brings microcomputer users the text 
editing and program development resources 
usually associated with much larger comput- 
ers," McCormack said. These include features 
that were not available on the original editor— 
the capability of editing very large files, func- 
tion keys that can be easily trained, file selec- 
tion by menu rather than human memory, the 
ability to edit a new file while still within an- 
other, and simplified keystroke sequences to 
accomplish the most common actions. 

"Because all commands derive from arbitra- 
ry key sequences, it is easy to customize ASE 
to most keyboards, giving manufacturers and 
systems houses great flexibility in the choice of 
terminals," McCormack continued. In addi- 
tion, he noted, ASE can take advantage of 
features such as the insert line capability that 
are found on more and more terminals today. 

Application developers can define the keys 
they want their users to have because ASE 
comes with a separate configuration program 
enabling redefinition of commands or capabili- 
ties based on the user or application. "Coupled 
with macros tailored to a software developer's 
application packages, enhanced, more effective 
packages result," he said. 

ASE is the only unbundled UCSD Pascal 
editor that is available without a full develop- 
ment system for distribution or incorporation 
into hardware and software systems. 

The software is fully supported for all ver- 
sions of the UCSD Pascal system. The IBM 
PC operates under UCSD Pascal systems as 
well as the Philips P2000, Digital's new Profes- 
sional series, the Xerox 820, and all Texas In- 
struments minis and micros including the Bus- 
iness Systems 2000 and the Home Computer. 
Versions of UCSD Pascal run on all major mi- 
crocomputer-based systems including those in- 
corporating 8080's, Z-80's, LSI IPs, 6502's, 
6800's, 6809's, 8086's, Z8000's, and 68000's. 
Apple Pascal is a UCSD Pascal derivative. 

The Advanced System Editor was designed 



specifically to improve productivity at the key- 
board during program development and text 
editing. It incorporates user-oriented conven- 
iences not usually found in microcomputer 
editors. 

"Because we are professional programmers 
with experience on a wide range of computers," 
McCormack said, "we included the features 
found on larger systems that we knew would 
speed work flow, and we eliminated bottle- 
necks and sources of frustration." 

The overall result has been to increase the 
capacity of files that can be edited, automate 
repetitive tasks, reduce keystrokes, and boost 
the capabilities of the editor so that memoriza- 
tion is minimized and almost all work can be 
done without extra manipulation outside the 
editor. 

File handling has been simplified immensely 
because the file size is limited by available disk 
space rather than by RAM memory size as 
was the case before, McCormack said. With 
ASE, a single file may fill an entire disk vol- 
ume, so users are not forced to juggle split files. 

User -defined function keys (macros), which 
are not available with the original UCSD Pas- 
cal screen editor, are another major benefit to 
users. These keys allow a user to automate 
tasks that recur within their particular pro- 
gram development or text editing environment. 

Any sequence of keystrokes, including edi- 
tor commands, can be "taught" to one of eight 
function keys. Once taught, pressing the func- 
tion key, in effect, causes the same keystroke 
sequence to be repeated. Such macros are easy 
to use, but powerful enough for complex oper- 
ations. Macros can, in fact, call other function 
keys, and they can also be used to make a 
change that affects an entire group of files. 

The function key remembers the sequence 
taught to it until the editing session ends or the 
key is redefined by the user. Definitions can be 
saved in a terminal-independent fashion within 
the file being edited or within libraries of 
definitions. 

"User-definable macros yield significant 
time savings for any task that must be done re- 
petitively but selectively," McCormack noted. 

In addition to user -definable function keys, 
Volition looked for other ways of reducing 
keystrokes and making keyboard time more 
productive. 

"The screen^oriented editor had already 
done some keystroke optimization, but we 
took it much further," McCormack said. 

Almost all moving commands are accom- 
plished with just one keystroke. Furthermore, 
they can be used in exchange or delete modes, 
whereas before the moving commands were 
only available at the outermost edit level. 

Single keystroke cursor positioning com- 
mands have been added to permit additional 
cursor movements such as moving word by 
word, moving backwards by a screen, moving 
to the beginning or end of a line, deleting by 
words, or returning to the home position. 



Variable tabs are also available. 

ASE lets the user recall search or replace- 
ment strings with a single keystroke. The 
editor also enables the user to move portions of 
the text horizontally (opening or closing 
space). This feature enables users to move col- 
umns of data relative to each other. 

Nested editing and menu selection of files 
are two important features that contribute to 
user satisfaction and reduce overhead. Now 
with ASE, both can be accomplished without 
having to leave the editor and go into the filer. 

With the previous editor, memorization was 
required because files were listable only by the 
filer, and that showed only the file name, size 
and date last used. However, ASE is designed 
to reduce memorization. There is a menu avail- 
able when entering the editor and when select- 
ing files to be copied. The first line of each file 
is available as a memory jogger. Furthermore, 
a menu of the file markers is available. 

"With ASE, menu selection makes the 'what 
file?' decision a one-character, multiple-choice 
answer by offering the selection of editable 
files and, if desired, the first lines of those 
files," McCormack said. Use of menus is not 
mandatory, however. 

Nested editing lets users work on one file, 
leave it to work on another or to retrieve infor- 
mation from another, then "pop" back to the 
precise place where they were working in the 
original file. Nested editing sessions can de- 
scend to a depth of six files, disk space permit- 
ting. As a result, it is possible to edit numerous 
files and move text from one file to another 
without leaving the editor. 

Other features of ASE not found in the orig- 
inal UCSD Pascal editor include extended, or 
"paint -mode," exchange, and change logging. 
With extended exchange, characters can be ex- 
changed, inserted or deleted anywhere on the 
screen. It's particularly useful to users who 
want to create character graphics or to rule 
tables because instead of being restricted to left 
to right movement, they can now type in any 
direction they want. 

Change logging allows the user to maintain 
a dated log of what was done in each editing 
session. That's an especially useful record to 
have if a number of programmers have worked 
on development of a program over a period of 
time. It is also useful for documents that have 
had multiple authors. 

"Most users spend the majority of their time 
entering or altering text with an inadequate 
editor, and their productivity and satisfaction 
suffer," McCormack said. "We believe ASE is 
a vastly improved tool for text manipulation." 

ASE is offered for distribution and sublicens- 
ing, with substantial discounts offered for 
quantity purchases. Telephone support is pro- 
vided. It is immediately available from Voli- 
tion Systems, P.O. Box 1236, Del Mar, CA 
92014, (714) 457-3865, with single copies for 
evaluation priced at $175.00. 

ASE object and source code are available. 
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ASE can be adapted for use on non-standard 
implementations of the UCSD Pascal system. 
Volition Systems works to improve the pro- 
ductivity of computer users and the quality of 
their tools. It concentrates on systems software 
development and on software development and 
hardware design. Volition specializes in Pas- 
cal, Modula-2 and related software, and it has 
designed hardware architectures for high-level 
languages under contract to other companies. 

™UCSD Pascal is a trademark of the REgents 
of the University of California. Apple is a 
trademark of Apple Computer, Inc. 

ASE™ — The Advanced System Editor™ 

Still using the standard screen editor? 

If so, you're wasting your time! ASE, the 
Advanced System Editor, will significantly in- 
crease your editing throughput. ASE lets you: 

• Reduce the number of keystrokes you have 
to type. 

• Select files for editing without ever having 
to invoke the filer. 

• Automate repetitive editing tasks with func- 
tion keys, so you can sit back and relax 
while ASE does the editing for you. 

If you aren't convinced that ASE is an abso- 
lute necessity, ask any ASE user or try it your- 
self. Once you've used ASE, you'll never want 
to go back! 



editor "pops" back to the previous edit ses- 
sion. The copy buffer is saved across nested 
edit sessions, allowing you to easily move 
text from one file to another. Edit sessions 
can also be chained together, allowing you 
to edit a series of files without leaving the 
editor. 

5) File menu selection: ASE displays a menu 
of available text files when you type "?" to a 
file name prompt. You no longer have to 
memorize all the files on your disks, or con- 
stantly flip between the filer and editor 
while editing a number of files. Typing "?" 
to the file menu prompt displays the first 
text line in each listed file, helping you to 
remember the contents of each file. 

6) Function keys: Function keys can be 'train- 
ed' to remember a sequence of keystrokes; 
typing a function key causes it to auto- 
matically perform its routine. Function 
keys greatly simplify repetitive editing 
tasks; their power is limited only by your 
imagination. 

ASE is available now for all versions of the 
UCSD Pascal system. A 100 page manual is in- 
cluded. 

UCSD Pascal is a trademark of the Regents of 
the University of California. ASE and Ad- 
vanced System Editor are trademarks of Voli- 
tion Systems. 



What is ASE? 

ASE is a powerful text editor suitable for 
both word processing and programming envi- 
ronments. It incorporates many improvements 
into the standard UCSD Pascal screen editor. 
ASE features include: 

1) Large file editing: ASE is not limited by 
memory size when editing text files; you 
can edit files as large as an entire disk 
volume. Source and destination files can be 
specified to reside on different disks. 

2) Keystroke optimization: ASE introduces a 
number of single-keystroke commands 
which speed up editing: you can move to 
the next word, the next character occur- 
rence, the beginning or end of a line, or the 
previous screen. Most moving commands 
can also be used in eXfchange and D(elete, 
allowing you to delete to the next word, 
character occurrence, or end of the line. 

3) Extended exchange: Exchange mode allows 
you to insert, delete, or exchange charac- 
ters anywhere on the screen. Most edit 
commands can be invoked while in ex- 
change mode. The typing direction in ex- 
change mode can be changed to go up, 
down, or left, as well as right, making it 
easy to draw vertical lines and diagrams. 

4) Nested editing: ASE allows you to edit 
another file in the middle of an edit session; 
when the nested edit session is finished, the 
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THE HISTORY OF THE DISER 
MODULA COMPUTER 

1970 is an important date in the history of 
computers. It was then that Pascal was imple- 
mented and began its rise to enthusiastic ac- 
ceptance by the programming world. This 
easy-to-learn, well defined language was 
created by Dr. Niklaus K. Wirth of Zurich, 
Switzerland. 

Even as major universities, software houses, 
and computer companies were enhancing 
Pascal to suit their own particular needs, 
Wirth was assessing those needs and positing 
the next generation software development 
tool. The early stage of this new project was 
the creation of the language Modula. A re- 
search tool, Modula was not a general-purpose 
programming language, but rather a vehicle 
for Wirth to explore real-time control systems 
and for casting new light on the subject of 
assembly coding. 

A year's sabbatical at Xerox Palo Alto Re- 
search Center (PARC), gave Wirth further in- 
sight into the concept of modules and high- 
level programming languages. He went back to 
Switzerland in 1977 to begin the project which 
has brought to the world the Modula Computer. 

The research environment of the Institute 
fur Informatik at the ETH, Zurich, Switzer- 
land provided the freedom to enter into the 
deisgn of not only a language, but concurrent- 
ly the computer architecture best suited to im- 
plement the language. Initially, the language, a 
skillful blending of Pascal and Modula and 
called Modula-2, was compiled and run on a 
PDP-11. This was quickly followed, in 1979, 
by the first prototype of the new computer- 
then called the Lilith. By 1980, the Lilith had 
supported the software development Wirth 
had envisioned and ten Liliths were in use at 
the ETH. 

Limited production of the Lilith began at 
Modula Research Institute in Provo, Utah. By 
1981, twenty machines were in use with twen- 
ty more to follow in the year to come. These 
were situated primarily in the research and 
development areas of major universities and 
industries. 

In addition to proving to be the ideal work- 
station for software development, 1981 saw 



the addition of a laser beam printer to the 
Lilith, the LPB-10. Extensive text editing and 
formatting was a natural for this system giving 
the user camera-ready, typeset quality copy 
from the printer. 

A key component of this system was the 
Mouse. With three programmable buttons, 
many functions of text editing were greatly 
facilitated. Additional software, including bit- 
map graphics, coupled with the Mouse, sup- 
ported various design functions. 

It was time to bring this personal worksta- 
tion to the marketplace. In January, 1983, the 
DISER Corporation was formed to begin full- 
fleged production of the computer, henceforth 
to be known as the MODULA COMPUTER. 



MODULA-2 

The language Modula-2— the notation in 
which this system presents itself to the soft- 
ware engineer— is designed as a total systems 
programming language. An assembler is not 
needed. The language is suited to both high- 
level programming in a machine-independent 
manner and low-level programming of machine- 
dependent aspects, such as device handling 
and storage allocation. The entire operating 
system, the compiler, the utility programs, and 
the library modules are programmed exclusive- 
ly in Modula-2. 

The compiler is subdivided into four parts. 
Each part processes the output of its predeces- 
sor in sequential fashion and is, therefore, called 
a pass. The first pass performs lexical and syn- 
tactic analysis, and it collects identifiers, allo- 
cating them in a table. The second pass pro- 
cesses declarations, generating the so-called 
symbol tables that are accessed in the third 
pass to perform the type-consistency checking 
in expressions and statements. The fourth pass 
generates code; its output is called M-code. 

OPERATING ENVIRONMENT 

The operating system is an "open" system. It 
is divided into three principle parts; the linking 
loader, the file system, and routines for key- 
board input and text output to the display. The 



file system maps abstract files (sequences of 
words and characters) onto disk pages and pro- 
vides the necessary basic routines for creating, 
naming, writing, reading, positioning, and de- 
leting files. The loader and file system present 
themselves to the Modula-2 programmer as 
modules (packages) whose routines can be im- 
ported into any program. Whenever a program 
terminates, the basic operating system acti- 
vates the command interpreter which requests 
the file name of the next program to be loaded 
and initiated. 

The computer as "seen by the compiler" is 
implemented as a microprogrammed interpre- 
ter of the M-code. The M-code is designed with 
the principle goals of obtaining a high density 
of code and of making the process of its gen- 
eration relatively systematic and straight- 
forward. A high density of code is desirable not 
only n the interest of saving memory space, 
but also for reducing the frequency of instruc- 
tion fetches. A comparison between two differ- 
ent, but strongly related compilers, revealed 
that M-code is shorter than code for the 
PDP-11 by a factor of almost four. This sur- 
prising figure is clear evidence of the inap- 
propriate structure of conventional computer 
instruction sets, including those of most 
modern microprocessors that are still designed 
with the human assembly language coder in 
mind. 

COMPUTER HARDWARE 

The hardware consists of a central process- 
ing unit based on the Am2901 bit-slice proces- 
sor, a multi-port memory with 128K words of 
16 bits, a micro-code memory of 2K instruc- 
tions implemented with PROMs, a controller 
each for the display, the disk, and interfaces 
for the keyboard, a cursor tracking device called 
the mouse, and an RS-232 serial line interface. 
The central processor operates at a basic clock 
cycle of 150 ns, the time required to interpret a 
micro-instruction. The most frequently occur- 
ing M-code instructions correspond to aobut 5 
micro-instructions on the average. 

The display is based on the raster scan 
technique using 832 lines of 640 dots each. 
Each of these 532,480 pixels (picture elements) 
is represented in main memory by one bit. If 
the entire screen is fully used, its bitmap oc- 
cupies approximately 25% of memory. The 
display is refreshed through a 64-bit bus. The 
representation of each pixel in program ac- 
cessible memory makes the display equally 
suitable for text, technical diagrams, and 
graphics in general. 

In the case of text, each character is generat- 
ed by copying the character's bitmap into the 
appropriate place of the screen's bitmap. This 
is done by software, supported by appropriate 
microcoded routines, corresponding to special 
M-code instructions. This solution, in contrast 
to hardwrae character generators, offers the 
possibility to vary the character's size, thick- 
ness (boldface), inclination (italics), and even 
style. In short, different fonts can be displayed. 
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This feature, which is particularly attractive 
for text processing, requires a substantial 
amount of computing power to be available in 
short bursts. The writing of a full screen, i.e. 
conversion of characters from ASCII code to 
correctly positioned bitmaps, takes about one 
fourth of a second. Using a small font, a full 
screen may display up to 11,000 characters. 

The disk used is a Honeywell-Bull D-120 
cartridge disk with a capacity of lOMBytes and 
a potential transfer rate of 720 kB/s resulting 
in an actual rate of 60kB/s for reading or writ- 
ing of sequential files. Disk sectors, each con- 
taining 256 Bytes, are allocated in multiples of 
8 on the same track. Allocation is entirely 
dynamic, and hence no storage contraction 
processes are needed to retrieve "holes." 

The mouse is an input device that transmits 
signals to the computer which represent the 
mouse's movements on the table. These move- 
ments are translated (again by software) to a 
cursor displayed on the screen. The mouse also 
has three software-programmable buttons. 

Reference: Wirth, N., The Personal Computer 
Lilith, Report 40, Institute fur Informatik, 
ETH Zurich, Switzerland; April 1981 

Diser Corporation 
P.O. Box 70 
385 East 800 South 
Orem, Utah 84057 
Tel. 801-227-2300 
Telex 453213 

A COMPARISON OF 
MODULA-2 AND PASCAL 

Modula-2 — The Logical Successor to Pascal 

In the years following the entrance of Pascal 
into the realm of computer languages, Pascal 
became increasingly appreciated for a number 
of reasons: 

— clear definition of data structures and 
algorithms 

— detection of syntax programming errors 

— protection against illegal values being 
assigned to variables 

— overcoming, in most instances, the need 
for subsets 

Designed originally as a teaching language 
by Dr. Niklaus K. Wirth, the language tends to 
lead programmers to write well -structured pro- 
grams. In addition, it is relatively easy to learn 
and essentially self -documenting. 

As its popularity grew so did its 
"extensions". In particular, attempts to 
enhance real-time applications and I/O device 
handling. But these "solutions" created new 
problems. 

While the rest of the world tried applying 
"fixes" to Pascal, Wirth analyzed the needs 
that had been identified and answered them 
with a complete language, Modula-2. The 
basic advancements fall into four categories: 



1. module structure — 

Inherent management of complex program- 
ming problems occurs because Modula-2 
supports structuring them as individual 
tasks. 

2. separate compilation — 

The definition-module allows individual 
modules to be compiled separately without 
sacrificing error checking. 

3. real-time primitives — 

Coroutines allow for real-time program- 
ming operations are defined in one or two 
separate modules. These modules are the 
only ones needing revision as a program is 
transported to another computer. 

4. portability through encapsulated machine- 
dependent operations — 

Modula-2 programs are completely portable 

because machine-dependent programming 

operations are defined in one or two 

separate modules. These modules are the 

only ones needing revision as a program is 

transported to another computer. 

In summary, Modula-2 is the logical successor 

to Pascal, it provides the solutions to Pascal's 

problems: 

Pascal's Problems Modula-2's Solutions 

fixed arrays open arrays 

global variables only local variables also 
lack of separate com- separate compilation 
pilation hindering providing libraries 

large complex of modules 

programs 

rigid order of related declarations 

declarations may be grouped 

Boolean expressions evaluations of condi- 
are not conditionally tions are ordered 
evaluated allowing branching 

upon satisfaction 
limited I/O standard library 

facilitation of I/O modules 

does not allow low- controlled low-level 
level programming access providing 
machine-level 
programming 



VOLITION SYSTEMS 

Dear fellow USUS Member: 

You've probably had an experience like this: 

• You spent two agonizing days hunting 
down a mysterious system bug. The cause? 
You changed a UNIT last week and forgot to 
recompile a program that uses it. 

• You gave up trying to use your serial card 
with interrupts— it was too hard to program in 
assembly and too slow in Pascal. 

• You like UCSD or Apple Pascal™, but 
have some doubts about it— everyone keeps 
saying the future belongs to UNIX™. 



You're frustrated, yet you stick with UCSD. 
After all, look at the alternatives! 

Anyway, that's how I felt before discovering 
Modula-2, Niklaus Wirth's latest program- 
ming language. EE Times, a leading electron- 
ics newsweekly, has called Modula-2 "the suc- 
cessor to Pascal." They're right. 

With Modula-2, I'm more productive 
writing and maintaining code, and I can do 
things that just weren't possible with the Pascal 
system. Better yet, 111 be able to move my pro- 
grams to other operating systems, thanks to 
the standard library Volition Systems provides 
with all its Modula-2 implementations. 

Because you already know Pascal, you'll be 
able to pick up Modula-2 in a matter of hours 
and become proficient in less than a week. 
Furthermore, Modula-2 is based on the effi- 
cient II.O architecture and is compatible with 
your existing UCSD Pascal and Apple Pascal 
software. 
Sincerely, 

Roger T. Sumner 
Chief Programmer 

UCSD Pascal is a trademark of the Regents of 
the University of California. UNIX is a 
trademark of Bell Laboratories. Apple is a 
trademark of Apple Computer, Inc. ASE is a 
trademark of Volition Systems. 



What is Modula-2 

The Modula-2 programming language was 
designed by Niklaus Wirth, Pascal's creator, as 
a simple but powerful alternative to assembly 
language, Pascal, 'C, and Ada. Modula-2 is 
easily learned by Pascal programmers, and it 
solves Pascal's problems in a consistent and 
structured fashion. Modula-2 language fea- 
tures include modules, concurrent processes, 
separate compilation, dynamic array parame- 
ters, and low-level machine access. 



Modula-2 on UCSD Pascal 

Modula-2 on UCSD Pascal is a software de- 
velopment system based on the version II 
UCSD Pascal system. The Modula-2 compiler 
accepts the full language with minor imple- 
mentation restructions. Programs are com- 
piled into P-code. 

Separate compilation is fully supported, 
with up to 50 separately compiled modules per 
program. No linking is required— module bind- 
ing is performed at run time. Modula-2 pro- 
grams can call other programs as procedures. 
Interrupts are fully supported, allowing real- 
time programming in Modula-2. System-de- 
pendent library modules provide access to the 
UCSD Pascal file system and UCSD Pascal in- 
trinsics. Standard library modules provide 
Modula-2 programs with a standard operating 
environment. 
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Standard Library 

Standard library modules are implemented 
either as a stand-alone system or as an inter- 
face to an underlying operating system. Be- 
cause all implementations present the same 
module interfaces, programs that use standard 
library modules are portable across all Modu- 
la-2 systems. Standard library facilities include: 

1) Console I/O: The module InOut includes 
routines for reading and writing basic data 
types to the standard input and output files. 
Standard I/O defaults to the system console, 
but can be redirected to disk files. The mod- 
ule Terminal provides console input and 
output and keyboard polling. 

2) File I/O: The modules Texts provides 
routines for reading and writing basic data 
types to text streams. The module Files in- 
cludes routines for reading and writing byte 
streams and arbitrary data types to files. 
Random and sequential file access is sup- 
ported. Directory operations allow pro- 
grams to change disk file names or delete 
disk files. 

3) Storage management: The module Storage 
includes routines for dynamic variable allo- 
cation and deallocation. Storage can allo- 
cate variable-sized buffers and indicate 
whether a given amount of storage is avail- 
able. 

4) Program execution: The module Program 
enables a Modula-2 program to call other 
programs as procedures. In addition to pro- 
viding code overlays, this facility simplifies 
the construction of large software systems; 
major parts en be written and tested as in- 
dividual programs before being incorpor- 
ated into the system as subprograms. Mod- 
ula-2 programs and subprograms communi- 
cate by sharing library modules. 

5) Exception handling: The modules Texts, 
Files, and Program include facilities for 
program control of run -time error handling 
and recovery. 

6) Process scheduling: The module Process- 
Scheduler provides process scheduling and 
synchronization facilities via the type 
SIGNAL and the procedures WAIT and 
SEND. 

7) Strings: The module Strings includes the 
string operations Insert, Delete, Pos, Con- 
cat, and Length. 

8) Decimal arithmetic: The module Decimals 
provides decimal arithmetic and COBOL- 
style formatting routines suitable for busi- 
ness applications. 

9) Math functions: The module MathLibO in- 
cludes the mathematical functions sin, cos, 
arctan, exp, In, and sqrt. 

System Components 

The Modula-2 system includes a fast one- 
pass compiler, library manager utility, and a 



module library. Standard library modules pro- 
vide I/O, program execution, storage alloca- 
tion, strings, math functions, and decimal 
arithmetic. A copy of Niklaus Wirth's new 
book Programming in Modula-2 is provided 
along with complete system documentation. 

System-dependent Facilities 

In addition to the standard module library, 
the Modula-2 system provides access to sys- 
tem-dependent facilities. On the Apple II and 
///, special modules are provided to access Ap- 
ple graphics and peripheral devices, and the in- 
terrupt system connects to the Apple hardware 
interrupt system. A utility program is also pro- 
vided which can convert Apple Pascal intrinsic 
units into library modules. 

On the Sage, a special library module is pro- 
vided for performing 32-bit arithmetic, and the 
interrupt system connects to the event system 
defined in the Sage BIOS. Note that the Sage 
system includes UCSD Pascal-based system 
software and utilities. 

Modula-2 versus UCSD Pascal™ — 
Seven Significant Differences 

1) Modules versus units — Modula-2 divides 
its separately compiled modules into separate 
definition and implementation modules, allow- 
ing version control and easier library manage- 
ment. UCSD Pascal bundles a unit's interface 
and implementation parts into one compila- 
tion, preventing version control and making 
library management awkward. Modula-2's im- 
port/export statements and identifier qualifica- 
tion (e.g. "modulename.ident") provide explicit 
scope control over identifiers obrained from 
other modules. UCSD Pascal offers no identifi- 
er scope control between units. Finally, Modu- 
la-2 allows the declaration of local modules to 
improve the organization of compilation units. 
UCSD Pascal does not allow local units. 

2) I/O and Storage Management — Modu- 
la-2 provides all I/O and storage management 
routines as library modules, allowing such 
routines to be redefined or removed from the 
runtime system. UCSD Pascal I/O and storage 
routines are hardwired into the operating 
system. 

3) Concurrency — Modula-2 provides co- 
routines as the basic form of concurrency. Co- 
routines are simpler and faster than UCSD 
Pascal semaphores, and can also be used to 
construct most forms of process scheduling: 
rendezvous, message passing, signals, or 
semaphores. 

4) Low-level Programming — Modula-2 
provides explicit language features for low- 
level programming: type transfer functions, 
absolute-address variable declarations, bitsets, 
address arithmetic, and interrupt handling. In 
UCSD Pascal, low -level programming relies on 
assembly language or unsafe programming 
tricks which violate the Pascal language. 



5) Parameters — Modula-2 provides proce- 
dure types: they are a generalization of Pascal's 
procedure parameter, and permit the defini- 
tion of procedure parameters and procedure 
variables (a powerful concept new to most Pas- 
calers). Modula-2 also provides open array pa- 
rameters which accept arrays of any size. 
UCSD Pascal provides neither the procedure 
parameters nor conformant arrays defined in 
standard Pascal. 

6) Statements & Expressions — Modula-2 
provides a LOOP/EXIT statement, a FOR 
statement with arbitrary step values, and a 
CASE statement with an ELSE part and sub- 
ranges allowed in case constants. Functions 
can return any type as a function result. Mod- 
ula-2 defines short-circuit Boolean expression 
evaluation for simpler and more efficient pro- 
gramming. Constant expressions may appear 
anywhere a constant is allowed. Pascal pro- 
vides none of these useful features. 

7) Syntax — Modula-2 programs are more 
readable than Pascal. Identifiers are significant 
to any length (not just the first 8 characters). 
The INC and DEC procedures eliminate the 
need for 'i: = i + 1' statements. There is no BE- 
GIN/END statement, because structured 
statements (IF, WHILE) are terminated by 
END. 



VOLITION INTRODUCES 
MODULA-2 FOR IBM PC 

Niklaus Wirth's new programming language, 
Modula-2, is commercially available on the 
IBM Personal Computer for the first time, ac- 
cording to Volition Systems in Del Mar, CA. 

Modula-2 comes as part of a complete soft- 
ware system based on a version II UCSD Pas- 
cal* operating system. The system, developed 
by Volition, features a fast, easy-to-use version 
of Modula-2 and works well even in the 64K 
IBM PC environment, a feat not achieved by 
other UCSD Pascal -based systems. 

Wirth developed Modula-2 to overcome 
real -world deficiencies he recognized in Pascal, 
which he created earlier as a teaching lan- 
guage. The new language— designed to utilize 
standard software modules — offers great flex- 
ibility in the development of large, complex 
systems. It is paticularly suited for large in- 
dustrial and commercial applications. 

Volition's implementation of the new lan- 
guage offers a two-fold savings for software 
program developers using the IBM PC, accord- 
ing to Joel J. McCormack of Volition. 

First, the use of standard software modules 
and separate compilation with automatic ver- 
sion control can save time and money during 
program development and maintenance. 

"In addition, program developers will wel- 
come Modula-2's portability," McCormack pre- 
dicted, "because programs written in Modula-2 
for the IBM PC are directly transferable to the 
Apple II system. In effect, they can double 
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their target market with a very minimal 
effort." 

Volition's Modula-2 system for the PC in- 
cludes a comprehensive module library, Modu- 
la-2 compiler, and tutorial programs designed 
to bring Pascal programmers up to speed on 
Modula-2 in a matter of hours. 

The implementation makes special provi- 
sions for the needs of software developers, pre- 
senting a nicely integrated development envi- 
ronment. The compiler and editor communi- 
cate with each other to reduce development 
time, modules are dynamically linked so there 
is no separate linkage process required, and 
friendly user interface and consistent prompts 
are provided. 

All the attractive features of Modula-2 are 
provided: low-level machine access, real-time 
control, concurrent processes, and type-secure 
separate compilation with automatic version 
control. 

Real number and transcendental mathemat- 
ical support is provided directly by the 8087 
numerics processor. Performance using the 
8087 is considerably faster than it would be 
without it. 

"Interrupt handling is fully supported— pro- 
grammers can now write real-time or multi- 
tasking applications in Modula-2 instead of 
resorting to error -prone assembly language," 
McCormack said. 

Volition's unique development in the imple- 
mentation is the standard library, a collection 
of modules that offers facilities normally pro- 
vided by an operating system. The library pro- 
vides console I/O, random access files, disk di- 
rectory operations, format conversion, strings, 
decimal arithmetic, storae management, pro- 
gram execution and process scheduling. The 
standard library provides a portable interface 
to the underlying operating system. 

"With Modula-2, you can develop portable 
software systems that run without change on a 
number of different operating systems," Mc- 
Cormack said. "This should be of obvious in- 
terest to software developers faced with 
writing applications which must run on all of 
today's popular microcomputers." 

In addition to the IBM PC system, Volition 
currently provides Modula-2 for the Apple II 
(under Apple Pascal*) and for the Apple /// 
(under SOS) and as part of a complete software 
system for computers based on the 8080/Z80 
and 68000 processors. 

Modula-2 for the IBM PC is immediately 
available from Volition Systems. The complete 
Modula-2 system includes Pascal and Modu- 
la-2 compilers, module library, the Advanced 
System Editor (ASE), p-NIX command shell 
(that provides a UNIX-like programming en- 
vi-ronment), and a complete set of utility 
programs. 

The system is priced at $595. Educational, 
retailer, and distributor discounts are 
available. 

Volition Systems concentrates on systems 



software development and on research and de- 
velopment in hardware and software. Since the 
company was founded in 1980, it has been a 
leader in the implementation and dissemina- 
tion of the Modula-2 language and other high 
level languages and in the design and develop- 
ment of advanced computer architectures. 



MRI ANNOUNCES MODULA-2 
COMPILER FOR IBM PC 

IBM PC owners can buy a full Modula-2 
compiler for only $40 from the Modula Re- 
search Institute, a nonprofit organization in 
Provo, Utah. MRI has adapted the compiler 
for the IBM PC from the original Modula-2 
compiler developed by Niklaus Wirth at the 
Institute for Informatics of the ETH in Zurich. 
The IBM PC compiler generates intermediate 
M-code similar in concept to the P-code of the 
original Zurich Pascal compiler. 

Although the 4-pass Modula-2 compiler re- 
quires more compile time than a single-pass 
Pascal compiler, it provides M-code that is 
30% more compact than the p-code and exe- 
cutes at least 20% faster. Use of M-code 
makes it possible to use programming tools 
transported from Wirth's Lilith, an optimized 
programmer's workstation that directly ex- 
ecutes M-codes and is also available from 
MRI. MRI is now developing an M-code-to- 
native-code translator for the IBM PC to opti- 
mize execution time on the IBM PC at the ex- 
pense of code compactness. 

The $40 compiler for the IBM PC runs 
under DOS 2.0, requires 128k of RAM and 2 
floppy disk drives, and is distributed with sam- 
ple programs on two single-sided IBM floppy 
disks. Source code for the compiler is available 
from MRI on IBM PC floppy or 9-track tape 
for an additional $160. MRI also has versions 
of the compiler for the 68000 and the PDP- 1 1 . 



MODULA-2 SOFTWARE FROM 
VOLITION TO LAUNCH 
SPRINGER- VERLAG LINE 

Volition Systems Modula-2 will be the first 
software offering from Springer- Verlag, the in- 
ternational publisher of scientific, technical 
and medical books and journals, according to 
Volition Systems in Del Mar, CA. 

Springer-Verlag New York Inc. will be han- 
dling Volition Systems Modula-2 software 
packages for worldwide distribution through 
the publisher's traditional retail channels. Voli- 
tion's implementation of Niklaus Wirth's new 
Modula-2 programming language will be avail- 
able for the Apple II and //e, the IBM Personal 
Computer and the Sage II and IV 
computers. 

Until now, Volition has concentrated on 



sales of Modula-2 to OEM's, systems houses, 
software developers and manufactueres. "This 
agreement will significantly expand our mar- 
keting effort at the retail level," according to 
Joel J. McCormack of Volition Systems. 

"We expect the broader availability of Mod- 
ula-2 software will spark additional interest in 
this superior new programming language, par- 
ticularly in the academic, scientific and tech- 
nical fields where Springer's titles are highly 
respected," he continued. 

Modula-2 software will be distributed as 
part of Springer's Computer Science Software 
Project and will be available beginning in Oc- 
tober. Also available from Springer is Niklaus 
Wirth's book Programming in Modula-2, 
which includes a complete description of the 
language. 

Wirth created Modula-2 (from MODUlar 
LAnguage) to overcome the real-world de- 
ficiencies of Pascal, a language which he previ- 
ously created. The new language uses modules 
to facilitate development and maintenance of 
large, complex software systems, making it es- 
pecially useful in large industrial, commercial 
and scientific applications. 

The Volition Systems Modula-2 is available 
as a complete software development system 
and includes a comprehensive set of standard 
library modules and utilities as well as tutorial 
programs, system documentation and Wirth's 
book. Springer-Verlag will package and pro- 
vide support for the systems it sells through its 
distribution channels. 

Volition Systems concentrates on systems 
software development and on research and de- 
velopment in hardware and software. Since the 
company was founded in 1980, it has been a 
leader in the implementation and dissemina- 
tion of the Modula-2 language and other high- 
level languages and in the design and develop- 
ment of advanced computer architectures. 

Springer-Verlag is a leading international 
scientific, technical and medical publisher with 
185 science journals and 900 new titles re- 
leased annually. Located in New York, Berlin, 
Heidelberg and Tokyo, it maintains a world- 
wide network of interlocking editorial, produc- 
tion, marketing and distribution centers and 
publishes reference works, original research 
and advanced texts. 
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UCSD Pascal System User's Society UCSD p-System User's Society 



us 



GET MORE FROM YOUR PASCAL SYSTEM 
.... JOIN USUS TODAY 

USUS is the USER'S GROUP for the most widely used, machine-independent 
software system. 

If you use UCSD Pascal*, Apple Pascal** orthe UCSD p-System, USUS will linkyou 
with a community of users that share your interests. 

USUS was formed to give users an opportunity to promote and influence the development of 
UCSD Pascal and the UCSD p-System and to help them learn more about their systems. USUS is non- 
profit and vendor-independent. 

Members get access to the latest UCSD p-System information and to extensive Pascal expertise. 
In USUS. you have formal and informal opportunities to communicate with and learn from other 
users via: 

. NATIONAL MEETINGS . SOFTWARE LIBRARY 

. USUS NEWS AND REPORT . SPECIAL INTEREST GROUPS 

. ELECTRONIC MAIL 

*UCSD Pascal and the UCSD p-System are trademarks ot the Regents of the University of California. 
"Apple Pascal is a trademark of Apple Computer inc 



USUS MEMBERSHIP APPLICATION 

(Please complete both sides) 



am applying for $25 individual membership 

$500 organization membership 
$ air mail service surcharge 



Rates are for 12 months and cover surface mailing of the newsletter. If you reside outside North 
America, air mail service is available for a surcharge. It is as follows: $5.00 annually for those in the 
Caribbean, Central America and Columbia and Venezuela; $1 0.00 annually for those in South America. 
Turkey and North Africa; and $1 5.00 for all others. Check or money order should be drawn on a U. S. 
bank or U.S. office. 



Name/Title 
Affiliation . 
Address 



Phone ( ) - TWX/Telex 



Option 
Option 
Option 



Do not print my phone number in USUS rosters 
Print only my name and country m USUS rosters 
Do not release my name on mailing lists 
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USUS MEMBERSHIP BENEFITS 

• • • • • 

• NATIONAL MEETINGS twice a year let you learn from experts and try out the newest products. 
Meetings feature hardware and software demonstrations, tutorials, technical presentations and 
information, reduced-cost software library access, special i nterest group (S I G) meetings, and a chance 
to query "major" vendors. 

• USUS NEWS AND RE PORT brings you news and information about your operating system four times 
a year. It contains technical articles and updates, library catalog listings. SIG reports, a software 
vendor directory and organizational news. 

• ELECTRONIC MAIL puts USUS subscribers in touch with a nationwide network of users. Compu- 
Serve MUSUS SIG is for data bases and bulletin board communications. GTE Telemail accommo- 
dates one-to-one messages. 

• SOFTWARE EXCHANGE LIBRARY offers an extensive collection of tools, games, applications, 
and aides in UCSD Pascal source code at nominal prices. 

• SPECIAL INTEREST GROUPS zero in on specific problems, represent member interests with 
manufacturers. 



For more information, contact: Secretary, USUS. P. 0. Box 1 1 48, La Jolla, CA 92038, USA. 



Computer System: 

Z-80 8080 

9900 



PDP/LSI-11 _ 

8086/8088 Z8000 



6502/Apple 
_ 68000 



6800 



6809 



MicroEngine 



IBM PC 



Other. 



I am interested in the following Committees/Special Interest Groups (SIGs): 



Advanced System Editor SIG 

Apple SIG 

Application Developer's SIG 

Communications SIG 

DEC SIG 

File Access SIG 

Graphics SIG 
, IBM Display Writer SIG 
, IBM PC SIG 



Meetings Committee 

Modula-2 SIG 

NEC Advanced PC SIG 

Publications Committee 

Sage SIG 

Software Exchange Library 

Technical Issues Committee 

Texas Instruments SIG 

UCSD Pascal Compatability SIG 



Mail completed application with check or money order payable to USUS and drawn on a U.S. bank or 
U.S. office, to Secretary. USUS. P.O. Box 1 1 48. La Jolla. CA 92038, USA. 



42 



Formerly Pascal News 

2903 Huntington Road 
Cleveland, Ohio 44120 



Please enter my □ New or □ Renew 

membership in Pascal Users Group. I understand I will receive "Pascal & 
Modula 2 "whenever it is published in this calendar year. 



Pascal & Modula 2 should be mailed 

1 year □ in USA $25 □ outside USA $35 

3 year □ in USA $50 □ outside USA $80 



□ AirMail anywhere $60 

□ AirMail anywhere $125 



(Make checks payable to: 
"Pascal Users Group," drawn on USA bank in US dollars) 



Enclosed please find US $ . 



. on check number . 



(Invoice will be sent on receipt of purchase orders. Payment must be 

received before magazine will be sent. Purchase orders will be 

billed $10 for additional work.) 



(I have difficulty reading addresses. 
Please forgive me and type or print clearly.) 



My address is: 

NAME 



ADDRESS 



PHONE 



COMPUTER 
DATE 



□ This is an address correction. Here is my old address label: 



Formerly Pascal News 

2903 Huntington Road 
Cleveland, Ohio 44120 



Back issues are requested and sent in sets. 



$15 D set Issues 1. 

$25 D set 1 Issues 9. 
$25 □ set 2 Issues 13. 
$25 □ set 3 Issues 17. 
$25 □ set 4 Issues 21. 



.8 (January 1974— May 1977) 
Out of Print 

.12 (September 1977— June 1978) 

.16 (December 1978— October 1979) 

.20 (March 1 980— December 1980) 

.23 (April 1981 [mailed January 1982] — 
September 1981 [mailed March 1982]) 



Requests from outside USA please add $5 per set. 



All memberships entered in 1983 will receive issue 24 and all other issues 
published in that year. Make check payable to: "Pascal Users Group," 
drawn on USA bank in US dollars. 



Enclosed please find US $ . 



. on check number . 



(I have difficulty reading addresses. 
Please forgive me and type or print clearly.) 



My address is: 

NAME 



ADDRESS 



PHONE 



COMPUTER 
DATE 
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Joining Pascal User Group? 

• Membership is open to anyone: Particularly the Pascal user, teacher maintainer, implementor, distributor, or just 
plain fan. 

• Please enclose the proper prepayment (check payable to "Pascal User's Group"). 

• When you join PUG any time within a year: January 1 to December 31, you will receive all issues of Pascal & 
Modulal for that year. 

• We produce Pascal & Modula2 as a means toward the end of promoting Pascal and communicating news of events 
surrounding Pascal to persons interested in Pascal. We are simply interested in the news ourselves and prefer to 
share it through Pascal & Modula2. We desire to minimize paperwork, because we have other work to do. 



Renewing? 

• Please renew early (before November) and please write us a line or two to tell us what you are doing with Pascal, 
and tell us what you think of PUG and Pascal & Modula2. 



Ordering Back Issues or Extra Issues? 

• Our unusual policy of automatically sending all issues of Pascal News to anyone who joins within a year means 
that we eliminate many requests for back issues ahead of time, and we don't have to reprint important information 
in every issue — especially about Pascal implementation! 

• Issues 1 . . .8 (January, 1974— May 1977) are out of print. 

• Issues 9. . . 12, 13. . . 16, & 17. . .20, 21 . . .23 are available from PUG(USA) all for $25.00 a set. 

• Extra single copies of new issues (current academic year) are: $10 each— PUG(USA). 



Sending Material For Publication? 



• Your experiences with Pascal (teaching and otherwise), ideas, letters, opinions, notices, news, articles, conference 
announcements, reports, implementation information, applications, etc. are welcome. Please send material single- 
spaced and in camera-ready (use a dark ribbon and lines 15.5 cm. wide) form. 

• All letters will be printed unless they contain a request to the contrary. 
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Facts about Pascal, THE PROGRAMMING LANGUAGE: 

Pascal is a small, practical, and general-purpose (but not all-purpose) programming language possessing 
algorithmic and data structures to aid systematic programming. Pascal was intended to be easy to learn and 
read by humans, and efficient to translate by computers. 

Pascal has met these goals and is being used successfully for: 

• teaching programming concepts 

• developing reliable "production" software 

• implementing software efficiently on today's machines 

• writing portable software 

Pascal implementations exist for more than 1 05 different computer systems, and this number increases every 
month. The "Implementation Notes" section of Pascal News describes how to obtain them. 

The standard reference ISO 7185 tutorial manual for Pascal is: 

Pascal — User Manual and Report (Second, study edition) 
by Kathleen Jensen and Niklaus Wirth. 
Springer-Verlag Publishers: New York, Heidelberg, Berlin 
1978 (corrected printing), 167 pages, paperback, $7.90. 

Introductory textbooks about Pascal are described in the "Here and There" section of Pascal News. 

The programming language, Pascal, was named after the mathematician and religious fanatic Blaise Pascal 
(1623-1662). Pascal is not an acronym. 

Remember, Pascal User's Group is each individual member's group. We currently have more than 3500 active 
members in more than 41 countries. 
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If the number on the mailing label in brackets is not [84] or higher, 
it is time to renew for 1984. Please detach and mail the self-addressed card below. 




Renew my subscription for 1 984 

it $25 for the year. 

S Check Enclosed 
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